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1.0  Introduction 

The  Synthetic  Theater  of  War  Architecture  (STOW-A)  is  an  evolutionary  application  of 
the  Distributed  Interactive  Simulation  (DIS)  technologies.  It  is  defined  as  a  suite  of 
hardware  and  software  used  to  link  live,  virtual,  and  constructive  legacy  simulations, 
which  will  support  prototyping  for  the  future,  study  and  testing  of  concepts  and 
equipment,  mission  rehearsal,  and  training.  This  program  is  designed  to  reuse  core 
components  and  products  for  rapid,  cost-effective  implementations  which  maximize 
interoperability  among  simulations. 

In  1994,  the  Synthetic  Theater  of  War  -  Europe  (STOW-E)  demonstration  provided  the 
first  step  toward  realizing  the  goal  of  a  global,  interactive  simulation  capability  to  support 
the  Army’s  training  and  testing  needs.  During  the  development  of  this  demonstration,  a 
number  of  key  technologies  required  to  support  large  and  complex  scenarios  were 
identified:  scalabability,  network  interfaces  and  translators,  computer  generated  forces 
(CGF),  and  virtual-constructive  interfaces. 

STOW-A  is  intended  to  provide  the  capability  to  support  unit  interactive  training, 
mission  rehearsals  and  experiments  at  the  Brigade  level,  as  well  as  compatibility  with 
future  object-oriented  Advanced  Distributed  Simulations  (ADS),  which  will  support  joint 
exercises.  The  focus  of  STOW-A  includes  development  efforts  required  to  field  a  tested 
system  with  the  capability  to  support  training,  mission  rehearsals,  and  experiments  within 
networked,  DIS  compatible  legacy  simulations. 

As  the  STOW-A  technology  matures,  the  possibility  of  creating  a  confederation  of 
models  with  constructive,  virtual,  and  live  components  opens  new  avenues  for  training. 
This  confederation  can  be  used  to  provide  vertical  as  well  as  horizontal  training  extending 
from  the  commanders  and  their  staff  to  individual  teams  practicing  collective  tasks.  As 
shown  in  Figure  1-1,  the  commander  and  his  staff  will  interface  with  a  constructive 
representation  of  the  battlefield,  while  field  units  operating  in  manned  simulators  operate 
within  the  same  battlefield  in  the  virtual  world,  and  field  units  in  vehicles  interface  to  the 
same  battlefield  in  the  live  world. 
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-  Common  view  of  the  battlefield 


-  Fully  digitized  battlefield 

-  Same  playbox/terrain 

-  Widely  separated  sites 


•  Manned  Simulators 
-Aviation  Test  Bed 

-  Mounted  Warfare  Test  Bed 

-  USA/USN  Systems 


Figure  1-1  The  STOW-A  Concept 


The  STOW-A  concept  provides  a  DIS-based  interface  between  constructive  simulations 
and  virtual  simulators  interacting  on  overlapping  digital  terrain  databases.  This  interface 
has  evolved  through  several  exercises;  it  has  been  modified  to  take  advantage  of 
improvements  in  the  Semi- Automated  Forces  (SAF)  system  representing  the  virtual  side 
of  the  interface,  restructured  to  open  its  architecture,  enhanced  to  improve  the  translation 
of  functionality  between  the  two  different  types  of  simulation,  and  tested  with  increased 
rigor  to  establish  stable  performance.  The  STOW-A  Exercise  1996  (STOWEX  96) 
baseline,  STOW-A  version  1.5,  links  the  constructive  Brigade/Battalion  Battle 
Simulation  (BBS)  with  the  virtual  world  of  manned  simulators  through  an  interface  to  the 
Modular  Semi-Automated  Forces  (ModSAF).  As  shown  in  Figure  1-2,  this  interface 
consisted  of  BBS  version  4.2,  a  translation  function  called  the  Opstate  Interpreter 
(OPSIN),  and  a  set  of  ModSAF  processors  (called  the  “Farm”)  that  executes  the 
movements  of  entities  converted  from  aggregated  BBS  units  to  individual  (disaggregated) 
virtual  vehicles  and  representations  of  manned  simulators. 
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OPSIN:  Operational  State  Interpreter 


1.1  STOWEX  96  Executive  Summary 

The  purpose  of  STOWEX  96  was  to  support  1st  Brigade  Combat  Team  (1BCT)  training 
utilizing  the  STOW-A  hardware  architecture  and  software  version  1.5.  The  STOWEX  96 
exercise  was  conducted  3  through  6  September  1996,  with  the  objective  to  train  the  1BCT 
in  the  same  type  of  missions  and  OPTEMPO  expected  during  a  National  Test  Center 
(NTC)  rotation.  Equipment  and  personnel  from  the  National  Simulation  Center  (NSC)  at 
Fort  Leavenworth,  the  Fort  Riley  Battle  Simulation  Center  (BSC),  the  Mounted  Warfare 
Test  Bed  (MWTB)  and  the  Mounted  Warfare  Simulation  Training  Center  (MWSTC)  at 
Fort  Knox,  and  the  Aviation  Test  Bed  (AVTB)  at  Fort  Rucker  were  utilized  in  support  of 
the  training  exercise. 

The  following  STOWEX  96  objectives  were  achieved: 

•  Supported  the  training  objectives  of  the  1  st  Infantry  Division; 

— Achieved  goal  of  500+  local  entities  on  the  ModSAF  Farm  during  Functional 
Test  II  and  reached  406  local  entities  during  exercise  (area  defense)  (Reference 
Appendix  G,  Test  Logs  for  additional  test  conditions  and  entity  count 
information); 

— Provided  a  reliable,  stable  virtual  simulation  and  interface  in  support  of 
STOWEX  96; 
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•  Populated  STOWEX  96  sites  with  appropriate  STOW-A  hardware  and  software 
suites  which  provide  a  DIS  environment  for  training; 

— Installed  and  integrated  STOW-A  suite  hardware  and  software  which  provided 
view-port  /  exercise  control  /  After-Action  Review  capabilities  at  the  BSC; 

— Installed  and  integrated  STOW-A  suite  hardware  and  software  which  provided 
view-port  capabilities  at  the  Army  Simulation  Center  (ASC); 

— Upgraded  ModSAF  Farm  and  OPSIN  capabilities,  installed  and  integrated 
stealth  and  Sound  Storm  capabilities  in  the  technical  control  and  visitor  center, 
at  the  NSC; 

— Configured  Observer  Controller  (OC)  support  SAF stations  at  the  MWTB  and 
the  AVTB; 

•  Matured  STOW-A  technology; 

— Implemented  and  verified  changes  for  problems  identified  during  both  Prairie 
Warrior  95  (PW95)  and  STOWEX  96  integration  and  test; 

— JnteuratedPlayed  the  Low-cost  Reconfigurable  Simulators  (ARSI,  RCVS,  and 
Dial-a-Tank)  during  into  the  STOW  environment  for  the  first  time.  LRS's  were 
used  in  exereiseCS  and  CSS  roles  during  the  exercise  ; 

— Upgraded  the  NSC  STOW-A  hardware  to  SGI  R10000  machines  and  IRIX  6.2, 
providing  increased  capacity  and  stability; 

•  Provided  a  more  realistic  simulation  for  tactical  communications  with  the  use  of 
the  RT-31/TP-8  interface  to  the  actual  field  radios; 

•  Generated  and  validated  structured  procedures  for  system  startup,  recovery  and 
shutdown; 

•  Reduced  the  number  of  contract  personnel  required  to  support  the  exercise; 

•  Performed  video  teleconferences  (VTCs)  between  Fort  Knox  and  Fort  Riley 
concurrently  with  the  running  of  the  exercise  validating  Defense  Simulation 
Internet  (DSI)  "dual  homing"  capability. 

1.2  Purpose 

This  final  report  for  the  STOWEX  96  Delivery  Order  will: 

•  Provide  the  information  and  guidelines  required  to  conduct  a  STOW-A  exercise, 

•  Identify  issues  and  resolutions, 

•  Define  the  system  baseline, 

•  Describe  training  objectives,  and 

•  Describe  the  technical  objectives. 
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1.3  Background 

1.3.1  STOW-E 

The  principle  of  integrating  constructive  and  virtual  simulations  was  first  demonstrated  in 
the  Advanced  Research  Projects  Agency’s  (ARP A)  STOW-E  exercise  in  the  fall  of  1994. 
BBS  provided  the  constructive  component  of  this  exercise.  It  was  linked  to  the  virtual 
world  by  means  of  the  Simulation  Network  (SIMNET)  predecessor  of  ModSAF. 
SIMNET  simulators  at  Grafenwoehr  provided  the  virtual  simulation  component  of  the 
exercise  and  the  Combat  Maneuver  Training  Center  (CMTC)  at  Hohenfels  provided  the 
live  component  of  the  simulation.  Additional  simulations,  including  ModSAF,  brought 
in  Air  Force  and  Navy  components.  All  these  components  were  linked  together  using  the 
DIS  protocols.  This  exercise  proved  that  the  concept  of  integrated  constructive,  virtual, 
and  live  simulations  was  technically  possible. 

The  connection  between  BBS  and  the  SIMNET  SAF  was  accomplished  by  means  of  two 
modules.  The  interface  to  BBS  was  a  program  called  Simulation  Control  (SIMCON). 
SIMCON  was  written  in  Ada,  executed  on  the  same  computers  as  BBS,  and  monitored 
and  modified  BBS’s  data  structures  so  that  BBS  could  interact  with  externally  simulated 
entities.  The  program  that  interfaced  with  the  SAF  was  the  Advanced  Interface  Unit 
(AUI)  developed  by  the  Navy  Research  and  Development  (NRaD)  This  program  took 
inputs  from  SIMCON  and  translated  them  into  commands  for  SIMNET  SAF  simulations. 
The  AIU  was  written  in  C  and  ran  on  multiple  single  board  computers. 

While  the  STOW-E  exercise  proved  that  combined  constructive,  virtual,  and  live 
exercises  were  possible,  there  were  a  number  of  problems: 

1 .  The  technology  was  too  immature  to  support  training  requirements. 

2.  The  simulation  was  able  to  generate  a  peak  of  approximately  1000  entities,  but 
it  could  not  do  so  reliably  for  any  reasonable  length  of  time. 

3.  There  was  limited  terrain  reasoning  or  interaction  with  rivers  due  to  the 
complexity  of  the  new  STOW-E  terrain  database,  and  dedicated  development 
personnel  were  required  to  keep  the  system  running. 

1.3.2  Prairie  Warrior 

In  the  summer  of  1994,  ARPA  and  NRaD  started  a  parallel  effort  to  use  ModSAF  instead 
of  SIMNET  SAF,  since  the  older  system  was  rapidly  becoming  obsolete  and  did  not 
support  DIS,  indirect  fire  weapons,  distribution  of  simulation  across  multiple  simulation 
hosts,  resupply,  or  the  increasing  complexity  of  the  terrain  databases  used  for  the 
simulation.  ModSAF  provided  a  more  reliable  and  extensible  virtual  component  at  the 
cost  of  some  initial  functionality. 
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During  the  Prairie  Warrior  95  effort,  initial  prototypes  inherited  from  the  ARPA  SIMNET 
program  were  upgraded  and  enhanced,  and  new  simulations  were  developed  to  allow 
models  to  interact  on  the  DIS  virtual  battlefield.  Enhancements  were  made  in  the 
ModSAF  system,  including  the  addition  of  limited  functionality  for  Combat  Support  (CS) 
and  Combat  Service  Support  (CSS)  functions  for  both  BBS  and  SIMNET  generated 
vehicles.  In  addition,  the  ModSAF  system  was  upgraded  to  allow  some  entity  migration 
from  one  workstation  to  another,  resulting  in  a  reduction  of  an  earlier  limitation  involving 
the  loss  of  entities  due  to  system  crashes. 

During  the  integration  and  testing  of  the  system,  problems  were  found  with  many  of  the 
features  supported  by  the  new  system.  In  some  cases  it  was  possible  to  fix  these 
problems  prior  to  the  start  of  the  exercise,  but  in  others  operational  work-arounds  had  to 
be  used.  With  the  aid  of  these  work-arounds,  the  exercise  was  run  successfully, 
demonstrating  that  ModSAF  could  support  constructive-virtual  training.  Significant 
achievements  included  operational  terrain  reasoning  and  obstacle  avoidance  supported  on 
the  Chorwon  terrain  database  (more  complicated  than  the  STOW-E  database)  and  the 
demonstration  of  fault  tolerant  operation  during  the  exercise  (a  ModSAF  simulation 
computer  crashed  without  being  noticed). 

The  following  technical  objectives  were  addressed  and  achieved: 

•  Correlation  of  behavior  between  entity-based  simulation  and  aggregate-based 
simulation. 

•  Correlation  of  synthetic  terrain  between  constructive  and  virtual  worlds. 

•  Correlation  of  fidelity  between  constructive  and  virtual  simulations. 

•  Support  for  “  dual-fight”  -  allows  one  constructive  unit  to  simultaneously  engage 
a  virtual  entity,  as  well  as  another  constructive  unit. 

•  Passing  Battle  Damage  Assessment  (BDA)  information  between  constructive  and 
virtual  worlds. 

Key  accomplishments  of  the  Prairie  Warrior  95  experiment  included: 

•  Development  of  the  BBS/OPSIN/ModSAF  Constructive/Virtual  interface; 

•  Enhancements  of  the  Application  Gateway  (AG),  Cell  Interface  Units  (XCIU), 
and  Translator  Cell  adapter  Units  (XCAU)  for  long  haul  networks; 

•  Enhancements  of  ModSAF  to  support  additional  entities,  simulator  placement, 
enhanced  Rotary  Wing  Aircraft  (RWA)  behaviors,  minefields,  and  the  OPSIN; 

•  Integration  of  BBS,  ModSAF,  SIMNET  Mis,  SIMNET  M2s,  SIMNET  RWAs, 
SIMNET  Stealth,  and  the  Simulation  TRaining  Integrated  Performance 
Evaluation  System  (STRIPES)  Stealth  and  After  Action  Review  (AAR);  and 

•  Wide  area  networking  of  five  field  sites. 
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After  Prairie  Warrior  95  was  completed,  a  list  of  Trouble  Reports  (TR)  was  generated.  In 
the  months  following  the  Prairie  Warrior  95  exercise,  the  approved,  prioritized  set  of  the 
appropriate  Trouble  Reports  was  addressed.  The  OPSIN  design  was  improved,  CS/CSS 
enhancements  of  ModSAF  2.1  were  addressed,  and  extensive  testing  was  performed  to 
improve  stability. 

1.3.3  STOWEX  96 

The  STOWEX  96  Delivery  Order  consists  of  five  phases:  Planning  and  Analysis, 
Exercise  Design  and  Development,  Integration  and  Test,  Exercise  Execution  and  Support, 
and  STOWEX  1.6  Delivery.  Preliminary  planning  encompassed  systems  engineering 
efforts  to  support  the  evolution  of  the  STOWEX  96  training  exercise.  Exercise  Design 
and  Development  provided  on-going  support  for  the  development  and  implementation  of 
the  STOW-A  96  exercise.  The  Integration  and  Test  Phase  was  performed  in  accordance 
with  the  Technical  Support  Plan.  The  Exercise  Execution  Phase  supported  the  execution 
of  the  STOWEX  96  exercise  from  3  through  6  September  1996.  The  final  phase,  which 
is  in  process,  includes  the  development  of  the  STOW-A  1.6  baseline.  STOW-A  1.6  will 
incorporate  corrections  to  deficiencies  identified  during  the  program  and  update  the 
software  baselines  for  specified  STOW-A  systems. 

The  STOWEX  96  effort  defined  an  infrastructure  consisting  of  those  computers  and 
equipment  necessary  to  support  the  following  functions: 

1 .  The  BBS  -  ModSAF  Linkage, 

2.  After  Action  Review  (STRIPES)  and  2  dimensional  (2D)  and  3  dimensional 
(3D)  display  capabilities, 

3.  Sound  system; 

4.  Plan  View  Display  (PVD), 

5.  Network  traffic  filtering, 

6.  SIMNET-DIS  translation, 

7.  wide  area  network  communications, 

8.  and  data  logging. 

These  functions  are  required  to  interface  BBS  with  ModSAF  and  manned  simulators 
including  SIMNET  RWA  simulators  at  the  AVTB  at  Fort  Rucker,  AL,  and  SIMNET  Ml 
and  M2  simulators  at  the  MWSTC  and  DIS  Limited  Reconfigurable  Simulators  in  the 
MWTB  at  Fort  Knox,  KY. 

Manned  simulators  were  provided  to  and  operated  by  the  field  units  that  had  been 
transported  to  the  AVTB  and  MWSTC/MWTB.  Each  of  these  field  units  operated  the 
available  manned  simulators  at  their  respective  sites  and  used  blue  forces  in  ModSAF  as 
“round-out”  units  to  bring  the  virtual  battallions  up  to  TOE  strengths.  STOWEX  96  also 
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provided  the  equipment  for  a  3D  and  2D  stealth  at  Fort  Riley  and  augmented  existing 
equipment  at  the  ASC  to  allow  the  ASC  to  serve  as  a  STOW-A  viewport. 

1.4  Document  Overview 

This  -document  provides  an  -overview  of  the  operational  concept  for  the  STOWEX  96 
Exercise,  a  brief  description  of  the  technical  components  of  the  sy  stem,  and  a  summary  of 
the  development  and  integration  and  test  cycles  as  well  as  the  execution,  of  the  STOWEX 
96  exercise,  including  the  issnes-and  resolutions. — This  document  consists  of:  The 
STOWEX  96  Final  Report  provides  a  summary  of  the  development,  integration, 
functional  test  and  execution  of  the  STOWEX  96  exercise.  An  overview  of  the 
operational  concept  for  the  exercise  is  provided  as  well  as  brief  descriptions  of  the 
technical  components.  Also  included  are  the  issues  and  resolutions  for  problems 
experienced  during  functional  testing  and  the  exercise.  This  document  consists  of: 


•  Section  1  provides  pertinent  background  information  of  related  STOW-A 
developments  and  exercises. 

•  Section  2  lists  applicable  documents. 

•  Section  3  identifies  Government  operational  concepts. 

•  Section  4  presents  a  summary  of  the  functions  performed  by  each  of  the 
STOWEX  96  components  as  well  as  their  software  and  hardware  platform. 

•  Section  5  summarizes  the  activities  performed  on  the  ADST  II  STOWEX 
Delivery  Order  to  date  (through  the  06  September  Exercise  and  post-exercise 
activities). 

•  Section  6  presents  the  issues  and  recommendations  that  resulted  from  this 
period  of  performance. 

•  Appendices  contain  Government  directives  for  the  exercise,  a  site  survey 
checklist,  mapping  data,  a  Communications  Users  Guide,  shipping  data,  test 
procedures  and  test  log,  the  Technical  Control  Plan,  equipment  disposition,  a 
sample  exercise  control  plan  outline,  and  a  sample  of  STOW-A  requirements. 
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2.0  Applicable  Documents 

2.1  Government  Documents 

ADST  II  Statement  of  Work  for  Synthetic  Theater  of 
War  Exercise  96  (STOWEX  96) 

1st  Infantry  Division  (M)  Exercise  Directive  for  1st  Bde 
Combat  Team  (1BCT)  BBS  (STOWEX)  Command 
Post  Exercise  DEVIL  WARRIOR  96-19. 

2.2  Contractor  Documents 

Standard  for  Information  Technology,  Protocols  for 
Distributed  Interactive  Simulation  Applications,  Entity 
Information  and  Interaction,  Version  1 .2 

Standard  for  Distributed  Interactive  Simulation- 

Application  Protocols  (draft) 

Proposed  IEEE  Standard  Draft  for  Information 

Technology,  Protocols  for  Distributed  Interactive 
Simulation  Applications,  Version  2.0,  3rd  draft 

Proposed  IEEE  Standard  Draft  for  Information 

Technology,  Protocols  for  Distributed  Interactive 
Simulation  Applications,  Version  2.0,  4th  draft 

ADST  II  CDRL  AB01  STOWEX  96  Report 

ADST  II  CDRL  AB03  Technical  Support  Plan  for 
STOWEX  96 

ADST  II  STOWEX  96  CDRL  AB06  Application 
Gateway  Version  Description  Document 

ADST  II  STOWEX  96  CDRL  AB06  STOW-A 
ModSAF  Version  Description  Document 

ADST  II  STOWEX  96  CDRL  AB06  OPSIN  Version 
Description  Document 

ADST  II  STOWEX  96  CDRL  AB06  SIMNET 
Simulator  Version  Description  Document 


STRICOM,  25  April  1996 
3-6  September  1996 


IEEE  1278-1993 


IEEE  Std  1278.1-1995 


IEEE  28  May  1993 


IEEE  16  March  1994 


Lockheed  Martin,  5  July  1996, 
ADST-II-CDRL-01 3R-9600220 

Lockheed  Martin,  3  June  1996, 
ADST -II-CDRL-0 1 3R-9600 1 93 

Lockheed  Martin,  7  October 
1996,  ADST -II-CDRL- 1 03R- 

9600346 

Lockheed  Martin,  7  October 
1996,  ADST-II-CDRL-01 3R- 

9600367 

Lockheed  Martin,  7  October 
1996,  ADST-II-CDRL-01 3R- 

9600347 

Lockheed  Martin,  7  October 
1996,  ADST-II-CDRL-01 3R- 

9600368 


9 


ADST-II-CDRL-01 3R-9600220-BA 

18  December-?- ■  October  1996 


ADST II  STOWEX  96  CDRL  AB06  STRIPES  Version  Lockheed  Martin,  7  October 
Description  Document  1996,  ADST-II-CDRL-013R- 

9600344 


ADST  II  STOWEX  96  CDRL  AB06  XCIAU  Version  Lockheed  Martin,  7  October 
Description  Document  1996,  ADST-II-CDRL-013R- 

9600345 
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3.0  STOWEX  Operational  Concepts 

The  exercise  intent  and  operational  concept  as  extracted  from  the  STOWEX  96 
Coordination  Message  #8  dated  2  September  96  was  as  follows: 

Intent.  The  purpose  of  STOWEX  96  is  to  support  1BCT  training  using  STOW-A 
version  1.5.  The  means  to  conduct  STOWEX  96  are  equipment  and  personnel  from 
the  National  Simulation  Center,  the  Fort  Riley  Battle  Simulation  Center,  The 
Mounted  Warfare  Test  /  Bed  SIMNET  Training  Facility,  and  the  Aviation  Test  Bed. 
The  expected  outcome  is  that  the  1BCT  is  trained  in  the  same  type  of  missions  and 
OPTEMPO  anticipated  during  NTC  Rotation  9705. 

Concept  of  the  Operation.  No  later  than  0322100  SEP  96,  STOWEX  96  will  be 
conducted  at  Fort  Riley,  Fort  Rucker,  Fort  Knox  and  Fort  Leavenworth.  The  STOW 
environment  will  be  used  in  the  training  of  the  1BCT.  Two  task  forces  (TF)  will  be  in 
BBS  at  Fort  Riley,  one  TF  will  be  in  SIMNET  /  ModSAF  at  Fort  Knox,  the  Attack 
Helicopter  battalion  will  be  in  SIMNET  /  ModSAF  at  Fort  Rucker.  The  BBS 
MicroVax  farm  (3100-95's),  located  at  the  Fort  Leavenworth  Technical  Control,  will 
be  remoting  via  modems  to  the  BBS  workstations  located  at  Fort  Riley.  The  ModSAF 
farm,  again  located  at  the  Fort  Leavenworth  provides  capability  to  perform  the 
disaggregated  fight.  Two  task  forces  <  TF)  will  be  in  BBS  at  Fort  Rilev.-one  TF  will 
be  in  SIMNET  /  ModSAF  at  Fort  Knox,  the  Attack  Helicopter  battalion-will  be  in 
S4-MNET  /  ModSAF  at  Fort  Rucker  and  Fort:  Leavenworth  will  host  the  BBS  MV 
3 1 00  95  VAX  Farm,  remoting  to  Fort  Riley  [workstations],  and-the-Sil icon  Graphics 
Incorporated  (SGI  )  ModSAF-  Farm  in  support  of  the  disaggregated  ■fight; 

3.1  Mission 

The  training  mission  as  defined  in  the  12  July  Exercise  Directive  was  as  follows: 

1BCT  conducts  a  brigade  level  BBS  driven  Command  Post  Exercise  utilizing  the 
COBRAS  Training  package  3-6  September  1996  at  the  Fort  Riley  BSC  and  Fort 
Rucker  BSC  in  order  to  prepare  for  NTC  rotation  and  support  the  STOWEX  test. 

1  st  Mission:  Area  Defense 

2nd  Mission:  Movement  to  Contact 

3.2  Training  Objectives 

The  1BCT  Training  Goals  and  Objectives  by  BOS  as  defined  in  the  12  July  Exercise 
Directive  were: 


11 


ADST-II-CDRL-01 3R-9600220-BA 

1 8  Decembers  October  1996 


Command  and  Control 


— Command  Control  the  BCT 
— Execute  and  improve  BCT  SOPs  and  Battle  Drills 
— Plan  and  develop  orders  effectively 

Maneuver 

— Defend 

— Plan  and  execute  a  BCT  R/S2  plan 
— Perform  a  Passage  of  Lines 
— Fight  a  Meeting  Engagement 

— Special  emphasis  on  security  operations  to  deny  battlefield  intelligence  to  the 
enemy 

— Concentrate  Combat  Power  effectively  on  the  Battlefield 
Fire  Support 
— Employ  Fire  Support 

— Employ  COLTs  as  an  effective  element  of  the  BCT's  deep  fight 
— Deliver  timely  and  accurate  Artillery  Fires 

— Plan  and  execute  effective  fire  support  plans  in  support  of  maneuver 
Intelligence 

— Plan  effective  reconnaissance  and  surveillance  operations 
— Prepare  effective  Intelligence  products  to  assist  the  orders  process 

Mobility.  Counter-Mobility  and  Survivability 

— Effective  engineer  recon  and  reporting 
— Mass  engineers  at  the  decisive  points 

— Effective  and  proper  integration  and  synchronization  of  obstacles 
— Positive  control  of  Engineer  equipment 

Air  Defense 


— Use  active  and  passive  Air  Defense  measures 
— Employ  ADA  scouts  ICW  with  R/S2  requirements 

Combat  Service  Support 

— Resupply  forward  elements  without  disruption  of  combat  operations 
— Monitor  and  accurately  track  BDE  operations 
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3.3  Operational  Environment 


For  this  exercise,  five  centers  of  activity  were  connected  via  the  DSI  network,  as  shown 
in  Figure  3.3.1.  Exercise  Control  and  elements  of  the  lsl  Infantry  Division  were  in  Fort 
Riley,  KS.  The  NSC  at  Fort  Leavenworth,  KS,  served  as  the  center  for  Technical 
Control.  Manned  simulators  at  the  MWTB  and  MWSTC  at  Fort  Knox,  KY,  and  the 
AVTB  at  Fort  Rucker,  AL,  participated  in  the  exercise.  In  addition,  a  viewport  at  the 
Pentagon  in  Washington  DC  was  provided.  Fort  Knox  and  Fort  Rucker  were  connected 
to  Fort  Riley  by  VTC  to  support  issuing  orders  and  providing  AARs.  Two  voice 
networks  supported  technical,  administrative,  and  tactical  coordination  between  sites. 
The  following  paragraphs  discuss  the  specific  configurations  at  each  location. 


Figure  3.3-1  STOWEX  96  Playing  Field 


3.3.1  Exercise  Control 

Fort  Riley  served  as  the  center  for  Exercise  Control  with  BBS  HICON  and  workstations 
that  were  linked,  via  commercial  phone  lines,  to  the  BBS  processors  at  NSC.  The  1st 
Brigade,  1ID  (Mechanized),  located  at  Fort  Riley,  KS,  was  the  focus  of  the  STOWEX  96 
training  exercise.  The  1ID  BSC  was  the  focal  point  of  the  training  with  components  of 
the  STOW-A  required  to  control  and  fight  the  virtual  and  constructive  simulated 
battlefield  as  described  below.  It  also  served  as  an  observation  site  for  visitors,  utilizing  a 
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multiple  large-screen-format  Stealth  viewing  system  for  concurrent  and  post-exercise 
viewing  of  the  virtual  battlefield.  The  Stealth  and  a  Sound  System  were  co-located  with  a 
BBS  AAR  station  for  monitoring  and  reviewing  the  BBS  elements.  There  were  no 
manned  simulators  at  the  Fort  Riley  node. 

Figure  3. 3. 1-1  provides  a  physical  layout  of  the  Fort  Riley  BSC  STOW-A  facility, 
Building  8388.  As  shown,  STOWEX  96  involved  four  primary  areas  of  the  BSC  to 
support  the  training  exercise:  Exercise  Control  Area,  the  Blue  Force  BBS  Area,  the 
OPFOR  Area,  and  the  AAR  Room. 


Figure  3.3. 1-1  Fort  Riley  Facility 
3.3.2  Technical  Control 

The  NSC,  located  at  the  “Beehive”  building  at  Fort  Leavenworth,  served  as  the  hub  site 
for  the  STOWEX  96  exercise,  responsible  for  the  Technical  Control  elements  of  STOW- 
A.  The  NSC  also  provided  an  observation  site  for  visitors,  utilizing  a  multiple 
large-screen-format  stealth  viewing  system  with  sound  for  concurrent  and  post-exercise 
viewing  of  the  virtual  battlefield.  A  BBS  “See  All”  station  that  reflected  the  BSC 
HICON  supported  monitoring  and  review  of  the  BBS  elements. 

The  hub  site  provided  the  primary  computational  assets  such  as  the  processors  for  BBS 
and  the  BBS-ModSAF  linkage  (OPSIN  and  Farm).  The  hub  site  also  served  as  the  center 
for  Technical  Control,  responsible  for  the  coordination  of  the  interfaces  to  remote  sites 
which  included  network  filtering,  master  application  gateway  control,  and  technical 
oversight 

NSC  had  the  responsibility  for  monitoring  the  exercise  to  ensure  that  all  of  the  elements 
responded  in  a  technically  correct  manner.  This  was  accomplished  through  the  use  of  a 
ModSAF  PVD  and  a  BBS  HICON. 
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Technical  Control  functions  also  included  monitoring  the  performance  of  the  OPSIN  and 
the  Farm  during  times  of  peak  activity  and  providing  manual  work  arounds,  if  required, 
to  insure  minimal  interruption  of  the  exercise. 

The  hub  site  also  provided  oversight  of  the  WAN,  determination  of  bandwidth  limitations 
and  resolution,  implementing  filtering  schemes  for  all  sites,  and  backup/recovery 
procedures  for  the  WAN. 

Figure  3. 3.2-1  provides  a  physical  layout  of  the  NSC  STOW-A  facilities.  Note  that  the 
BBS  workstations  were  not  used  during  the  actual  exercise  and  the  HICON  operated  as  a 
“  See  All”  workstation. 


Visitors  Center 

-  Stealth  (Onyx) 

-  Sound  Storm 

-  STRIPES 


Exercise  Control  J 

-  HICON  1 

-  OPSIN 

-  Logger 

-  Stealth  (Max  Impact) 

-  SAF  Control  . 

- PVD 


Exercise  Control 

-AG 

-  XCIAU 

-  ModSAF  Farm 


Adminstrative 

-  Micro Vaxes 

r 

Adminstrative 

-  Modem 

'  •;§ 

-  Muxes 

||| 

|| 

§ 

BBS 

-  BBS  WS’s 

| 

Figure  3.3.2-1NSC  STOW-A  Facilities 
3.3.3  Remote  Sites 

Fort  Knox  and  Fort  Rucker  were  remote  sites  that  augmented  the  exercise  with  manned 
simulators.  Fort  Rucker  provided  eight  SIMNET  RWA  simulators.  Fort  Knox  provided 
up  to  forty-one  SIMNET  Mis  and  nine  SIMNET  M2s  for  the  manned  portion  of  Task 
Force  2-34.  Fort  Knox  also  provided  CS/CSS  training  with  the  use  of  DIS  Limited 
Reconfigurable  Simulators.  As  indicated  earlier,  blue  forces  in  ModSAF  were  used  to 


15 


ADST-II-CDRL-0 1 3R-9600220-B  A 

1 8  Decembers  October  1996 


augment  each  site  to  round-out  the  manned  simulators  to  bring  each  unit  up  to  full 
strength. 

A  viewport  facility  located  at  the  DCSOPS  ASC  in  the  Pentagon,  Washington  DC,  was 
also  included  in  the  exercise. 

3.4  Operational  Scenario 

The  operational  scenario  is  provided  in  Appendix  A,  STOWEX  96  Exercise  Directive. 
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4.0  Technical  Descriptions 

The  STOWEX  concept  interfaces  constructive  simulation  provided  by  BBS  with  virtual 
simulation  (ModSAF)  and  virtual  simulators  (manned  SIMNET  or  DIS  ground  and  air 
platforms).  The  basic  STOWEX  infrastructure  consists  of: 

•  Constructive  simulation  (BBS) 

•  The  BBS-ModSAF  Linkage  (OPSIN,  ModSAF  Farm) 

•  Technical  Control  (SIMNET  -  DIS  Translations,  Network  Traffic  Filtering,  Data 
Logging) 

•  DIS  Stealth  and  AAR  (STRIPES) 

•  Network  Communications  (Local,  Wide  Area,  Application  Gateway) 

4.1  BBS 

BBS  is  a  constructive  wargame  developed  for  brigade  and  battalion  commanders  to  train 
their  battle  staffs  in  combat  and  battlefield  operations  procedures.  Combat  activities 
simulated  in  BBS  range  from  low-  to  high-intensity  warfare.  BBS  is  a  two-sided,  free- 
play  simulation  program  set  in  a  real-time  environment.  Brigade/Battalion  commanders 
and  their  staffs  exercise  command  post  skills  in  the  constructive  simulation  environment 
by  responding  to  real-time  combat  situations.  This  simulation  supports  maneuver,  fire 
support,  air  defense,  engineering,  Nuclear,  Biological,  Chemical  (NBC),  tactical  air,  air 
transport,  Army  aviation,  logistics,  maintenance,  medical,  personnel  administration, 
higher  headquarters  functions,  and  threat  operations. 

The  BBS  platform  is  a  set  of  Digital  Equipment  Corporation  (DEC)  MicroVAX  3100 
computers  connected  by  an  Ethernet  local  area  network.  A  BBS  workstation,  whose 
components  are  summarized  in  Figure  4.1-1,  provides  an  operator  with  the  ability  to 
control  units  and  subunits  allocated  during  system  initialization  in  accordance  with  the 
exercise  task  organization. 


Figure  4.1-1  BBS  Workstations 

Each  MicroVAX  drives  2  workstations  (graphics  monitors  to  display  map  and  equipment 
movement  overlays,  laser  disk  player,  and  personal  computer).  Sites  that  have  older 
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VAX  equipment  (i.e.,  MicroVAX  3100-40s)  must  be  upgraded  to  3100-96s  to  support  the 
addition  of  the  interface  to  ModSAF. 

4.2  ModSAF 

ModSAF  simulates  a  wide  range  of  air  and  ground  combat  vehicles  and  personnel 
including  tanks,  infantry  fighting  vehicles,  individual  combatants,  mortars  and  artillery, 
air  defense  systems.  Armored  Personnel  Carrier  (APCs),  command  posts  and 
maintenance  and  supply  vehicles,  aviation  elements,  close  air  support,  minefields  and 
breaching  equipment.  Simulation  of  entities  in  ModSAF  is  divided  into  the  behavioral 
and  physical  simulation.  ModSAF  physical  models  are  built  by  combining  model 
components  such  as  hulls,  turrets,  weapons,  and  sensors. 

A  ModSAF  PVD  provides  general  technical  control  capabilities,  such  as: 

•  Map  Scaling; 

•  Icon  Identification:  vehicle  ID,  bumper  number,  grid  coordinates,  vehicle 
type; 

•  Event  Identification:  artillery  round,  vehicle  hitting  a  mine,  direct  fire,  vehicle 
status,  etc.; 

•  Terrain  Features:  UTM  grid  lines,  water,  roads,  trees,  buildings,  power  lines, 
pipelines,  towns,  political  boundaries,  and  contour  lines; 

•  Ability  to  view  aggregated  BBS  units; 

•  Allow  operator  intervention. 

Monitoring  the  exercise  movement  at  the  ModSAF  PVD  is  performed  to  ensure  that  no 
inadvertent  activity  occurs.  For  example,  a  manned  simulator  that  enters  an  area  with 
aggregated  BBS  units  can  cause  unexpected  disaggregation  at  inappropriate  times  which 
may  have  adverse  effects.  Similarly,  a  constructive  unit  that  is  on  the  perimeter  of  a 
virtual  unit’s  sphere  of  influence  may  undergo  successive  disaggregations  and 
reaggregations  that  unnecessarily  stress  the  system  and  require  manual  intervention  to 
replace  individual  disaggregated  entities. 

4.3  BBS-ModSAF  Linkage 

The  BBS-ModSAF  linkage  includes  (1)  mapping  between  BBS  operational  states  and 
ModSAF  tasks  that  represent  different  approaches  to  simulating  common  activities  such 
as  resupply,  (2)  rules  for  aggregation  and  disaggregation  of  constructive  units  that  enables 
the  interaction  with  ModSAF  entities  and  the  soldier-in-the-loop,  and  (3)  support  for 
disaggregated  units  in  the  virtual  world  (ModSAF  Farm). 
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BBS  is  designed  for  training  battalion  and  brigade  staffs  and  does  not  simulate  the  exact 
location  or  direction  of  vehicles  in  a  unit.  As  a  consequence  of  not  simulating  the 
individual  vehicles  in  a  unit,  BBS  aggregates  cannot  directly  interact  with  manned 
simulators.  This  capability  is  achieved  through  the  BBS-ModSAF  Linkage  which  utilizes 
two  critical  concepts: 

•  aggregation  -  a  collection  of  individual  elements  into  a  unit,  indicated  by  its 
military  symbol,  and, 

•  disaggregation  -  the  disassembly  of  those  units  into  individual  entities,  each 
shown  as  a  single  vehicle  icon. 

When  a  virtual  entity  comes  within  a  certain  distance  (called  the  Sphere  of  Influence,  or 
SOI)  of  an  aggregated  unit  generated  by  BBS.  The  OPSIN  senses  the  virtual  entity 
position,  disaggregating  the  BBS  unit  by  directing  ModSAF  to  create  an  appropriate 
series  of  ModSAF  generated  entities  on  the  virtual  battlefield.  Orders  to  these  ModSAF 
generated  units  are  then  controlled  by  the  OPSIN  in  response  to  orders  from  the  BBS  side 
of  the  interface.  Events  on  the  virtual  battlefield  that  impact  the  state  of  these  BBS 
originated  elements,  such  as  disposition  of  virtual  forces  and  combat  outcomes,  are 
communicated  by  the  OPSIN  back  to  BBS  so  that  a  coherent  representation  of  forces  can 
be  maintained  between  the  virtual  and  constructive  simulations.  Units  that  involve 
human  operators,  such  as  SIMNET  simulators,  are  never  aggregated,  but  are  always 
represented  as  vehicles  in  BBS. 

Work  on  the  Legacy  Application  Adapteer  (LAA)  is  on-going  to  create  aggregate  units 
for  ModSAF  generated  vehicles  and  manned  simulators.  The  ModSAF  operator  selects 
vehicles  from  the  PVD  to  create  aggregates  with  the  specified  echelon  level.  Up  to  25 
vehicles  or  sub-aggregates  can  be  identified  for  an  aggregate.  Aggregated  units  are  then 
represented  in  the  virtual  world  through  the  experimental  Aggregate  State  PDU  which 
contains  the  unit’s  center  of  mass,  velocity,  orientation,  and  formation.  The  ModSAF 
operator  can  also  obtain  information  about  a  vehicle’s  aggregation  status  through  the 
same  user  interface. 

The  BBS-ModSAF  Linkage  is  comprised  of  BBS,  OPSIN,  a  Farm  (ModSAF  SAFSims), 
and  a  ModSAF  PVD.  The  ModSAF  Farm  consists  of  6  to  10  back-end  ModSAF 
computers  that  are  responsible  for  generating  the  disaggregated  entities  associated  with 
the  constructive  part  of  the  simulation.  The  PVD  provides  an  operator  interface  and 
shows  a  2D  view  of  the  terrain  and  all  of  the  constructive  and  virtual  participants.  For 
STOWEX  96,  the  Farm  required  7  back-ends  to  achieve  the  desired  number  of  virtual 
entities  ( 400). 

STOWEX  96  identified  an  upgrade  of  the  Indigo2  processors  used  previously  for  the 
OPSIN,  the  Farm,  and  the  Farm  PVD.  R4400s  used  during  Prairie  Warrior  were  replaced 
by  the  new  R1 0000s.  However,  the  Intel  Ethernet  card  and  SGI  software  driver  that  was 
used  with  the  R4400  Indigo2  was  not  compatible  with  the  IRIX  6.2  on  the  R10000 
systems.  In  order  to  provide  the  dual  Ethernet  capability  required  by  the  OPSIN  (to 
communicate  with  BBS  and  the  DIS  Ethernet),  a  new  Ethernet  card  from  Qualix  was 
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identified,  installed,  and  tested  successfully.  This  card  comes  with  a  firmware  driver. 
Table  4.3-1  summarizes  the  STOWEX  96  linkage  configuration. 


Table  4.3-1  BBS-ModSAF  Linkage  Configuration 


Name 

Quantity 

Source/V  endor 

Function 

Configuration/Identification 

MicroVA 

X 

10 

DEC 

BBS 

CPU:  3100-95 

SW  Version  4.2 

Indigo2 

1 

SGI 

OPSIN 

CPU:  Indigo2  R10000,  2GB  disk, 
256MB  RAM,  IRIX  6.2 

•  Qualix  Ethernet  card 

•  20"  color  monitor  and  keyboard 

•  OPSIN  compiled  for  IRIX  6.2, 
version  1.9  dated  28  June  1996 

Indigo2 

7  plus  1 
spare 

SGI 

! 

Farm 

•  CPUs:  Indigo2  R10000,  2GB  disk, 
128MB  RAM,  IRIX  6.2 

•  20"  color  monitors  and  keyboards 

•  ModSAF  sw  version  2.1  dated  28 
June  1996,  compiled  for  IRIX  5.3 

Indigo2 

1 

SGI 

PVD 

•  CPU:  Indigo2R  10000,  2GB  disk, 
256MB  RAM,  IRIX  6.2 

•  20"  color  monitor  and  keyboard 

•  ModSAF  sw  version  2.1  dated  28 
June  1996,  compiled  for  IRIX  5.3 

4.4  Technical  Control 

Technical  Control  is  comprised  of  support  equipment  used  by  personnel  to  ensure  that  the 
exercise  is  proceeding  without  hardware  or  software  problems.  Technical  Control 
components  include  the  DIS  translation  and  filtering  programs  (XCIAU  and  data  logging 
devices).  Table  4.4-1  provides  the  STOWEX  96  Technical  Control  components  and 
purpose. 


Table  4.4-1  Technical  Control  Components 


Component 

Purpose 

XCIAU 

(XCIU) 

Filter  out  ModSAF  PO  database  information  generated  by  the  Farm; 
allow  only  DIS  PDU  traffic  on  the  net 

XCIAU 

(XCAU) 

Translate  between  SIMNET  (RWA,  Ml)  and  DIS  PDUs;  filter  out 
ModSAF  PO  traffic 

Logger 

Record  DIS  PDUs 

The  XCIAU  has  combined  the  previous  XCAU  and  XCIU  functions  onto  a  single 
processor.  The  translation  function  of  the  XCAU  and/or  the  filtering  function  of  the 
XCIU  may  be  performed  on  a  single  workstation. 
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The  XCAU  provides  a  mechanism  of  translating  between  the  older  SIMNET  PDUs  and 
newer  DIS  PDUs.  The  function  is  bi-directional  providing  simultaneous  DIS  to  SIMNET 
and  SIMNET  to  DIS  translations.  The  user  interface  for  the  unit  is  used  to  display  on¬ 
line  statistics  and  provide  limited  control  over  the  conversion  process. 

Limitations  on  the  amount  of  network  traffic  that  individual  pieces  of  hardware  and  the 
network  itself  can  handle  have  created  the  need  to  provide  local  area  network  filtering. 
This  capability  is  furnished  by  the  XCIU  which  provides  a  gateway  between  two 
networks.  The  unit  provides  positive  filtering,  allowing  only  the  network  traffic  that  has 
been  specifically  identified,  to  pass  to  the  next  segment  of  the  network.  The  XCIU  was 
designed  for  SIMNET  and  DIS  systems  and  can  control  which  SIMNET  and  DIS  PDUs 
will  be  passed  through  the  system.  The  system  can  filter  PDUs  by  PDU  type,  range  or  in 
the  case  of  entity  state  PDUs  by  individual  entity.  One  use  of  an  XCIU  is  in  a 
BBS/ModSAF  system.  The  XCIU  is  placed  after  the  OPSIN  and  BBS  ModSAF  engines 
to  filter  the  Persistent  Object  Protocol  packets  from  the  rest  of  the  network.  Although  the 
XCIUs  are  normally  set  up  prior  to  the  exercise  and  do  not  require  any  further  attention, 
they  can  be  used  for  troubleshooting  network  problems  which  may  be  attributed  to  an 
overloaded  network. 

Data  Loggers  are  passive  devices  that  record  network  traffic.  This  information  can  then 
be  used  to  play  back  portions  of  a  virtual  simulation. 

Table  4.4-2  summarizes  the  XCIAU  and  Data  Logger  equipment. 


Table  4.4-2  Technical  Control  Equipment  Summary 


Name 

Description 

Location 

Function 

XCIAU- 

1 

Indigo2  R4400,  128MB,  2.0GB  System 
Disk,  IRIX  5.3,  Intel  Ethernet  card 

Hub,  remotes 

Filter  network  traffic  between  local 
network  and  wide  area  network 

XCIAU- 

2 

Indigo2  R4400,  128MB,  2.0GB  System 
Disk,  IRIX  5.3,  Intel  Ethernet  card 

Hub 

Filter  PO  traffic  from  ModSAF  Farm 
to  local  area  network 

XCIAU- 

3 

Indigo2  R4400,  128MB,  2.0GB  System 
Disk,  IRIX  5.3,  Intel  Ethernet  card 

Hub 

Filter  network  traffic  to  AAR 

XCIAU 

Indigo2  R4400,  128MB,  2.0GB  System 
Disk,  IRIX  5.3,  Intel  Ethernet  card 

Remote  with 
manned  sim 

Translate  between  SIMNET,  DIS 

XCIAU 

Indigo2  R4400,  128MB,  2.0GB  System 
Disk,  IRIX  5.3,  Intel  Ethernet  card 

Remote 

Filter  network  traffic  between  local 
network  and  wide  area  network 

Logger 

Indigo2  R4400,  128MB,  2.0GB  System 
Disk,  IRIX  5.3 

Archive  150  MB,  1/4”  tape  drive 

Archive  4-8  GB,  4  MM,  DAT  Tape 

Drive 

9  GB,  SCSI  disk  drive 

Dual  speed  CD  ROM  drive 

All 

Log  data  for  playback  on  STRIPES 
AAR 

4.5  DIS  Stealth  and  AAR 

The  3D  Stealth  provides  a  “window  into  the  virtual  battlefield”  which  allows  observers 
to  make  non-obtrusive  observations  of  the  action  occurring  within  the  virtual  world.  A 
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stealth  system  provides  a  three  dimensional  view  of  the  battlefield  similar  to  the  out-the- 
window  display  of  a  simulator.  Although  the  stealth  can  see  other  SIMNET  and  DIS 
entities,  it  is  not  able  to  be  seen  or  affected  by  these  entities.  A  stealth  can  be  flown 
through  the  battlefield  with  a  system  mouse  or  spaceball,  can  be  attached  to  another 
SIMNET/DIS  vehicle  or  can  be  teleported  directly  to  a  specific  location  through  the  use  a 
two  dimension  Plan  View  Display  of  the  battlefield.  Technical  Control  personnel  rely  on 
the  stealth  to  help  troubleshoot  movement  problems  by  identifying  the  source  of  the 
problem  (no-go  terrain,  unfordable  water  or  too  steep  of  slope). 

The  Government  Furnished  Equipment  (GFE)  STRIPES  software  provides  STOWEX  96 
with  a  stealth  and  an  AAR  capability.  STRIPES  provides  the  following  AAR  functions: 

•  Collect  data  broadcast  over  the  network  (vehicle  location,  vehicle  status,  and 
firing  events). 

•  Filter  and  organize  the  data  to  support  rapid  analysis 

•  Load  data  into  a  relational  database  (pattern  after  the  National  Training  Center) 

•  Integrate  broadcast  data  with  unit  planning  and  terrain  data,  and 

•  Provide  graphic  and  tabular  displays  of  data  to  support  individual  vehicle  and  unit 
performance  feedback. 

In  addition,  STRIPES  provides  the  capability  to  display  Experimental  Aggregate  State 
PDUs. 

STRIPES  may  be  hosted  on  either  an  SGI  Deskside  Onyx  or  a  Maximum  Impact  Indigo2 
with  an  Impact  Channel  Option  (ICO).  Both  platforms  have  the  capability  to  use  multiple 
large  screen  displays.  For  STOWEX  96,  three  37”  Mitsubishi  monitors  were  used  for 
each  STRIPES  platform.  At  the  NSC,  one  STRIPES  system  was  hosted  on  an  Onyx  and 
one  on  a  Maximum  Impact  to  support  both  the  Technical  and  Exercise  Control  rooms  and 
the  Visitor  Center.  At  Fort  Riley,  STRIPES  was  hosted  on  a  Maximum  Impact.  Since 
the  ICO  was  not  delivered  in  time  for  the  Exercise,  an  adapter  cable  that  interfaced  the 
Maximum  Impact  with  a  single  37”  monitor  was  used.  A  space  ball  served  as  the 
navigation  device  for  the  Onyx  while  a  mouse  was  used  for  the  Maximum  Impact.  A 
Sound  Storm  system,  provided  by  Reality  by  Design  on  a  Personal  Computer,  provided 
the  audio  for  vehicle  movements  and  collisions,  and  weapon  systems  detonations. 

4.6  Network  Communications 

STOWEX  96  uses  two  types  of  data  communications.  Within  each  site,  STOWEX 
components  transmit  and  receive  information  over  the  local  area  networks.  Wide  area 
networks  connect  the  NSC  hub  and  remote  sites. 

4.6.1  Local  Area  Network 

The  main  DIS  Ethernet  network  is  the  mechanism  through  which  all  simulation 
applications  ultimately  interact  with  other  applications  in  the  system. 
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The  hub  site  contains  a  BBS  network  and  multiple  DIS  Ethernet  networks.  BBS  uses  an 
Ethernet  network.  This  network  connects  to  the  ModSAF  Farm  subnet  through  the 
OPSIN  SGI  computer  with  dual  Ethernet  capability.  OPSIN,  the  Farm,  and  the  Farm 
PVD  are  on  a  DIS  (lOBaseT  Ethernet)  subnet  that  isolates  the  large  volume  of  ModSAF 
PO  traffic  required  for  the  Farm  from  the  main  DIS  network  and  keeps  unneeded  PDUs 
from  the  ModSAF  Farm  off  the  main  DIS  net.  This  subnet  is  connected  to  the  BBS 
network  via  the  dual  ported  OPSIN  and  to  the  main  DIS  network  through  an  XCIAU. 
The  Technical  Control  stealth  system  is  on  a  DIS  subnet,  and  the  Visitor  Control  AAR 
system  is  on  another  DIS  subnet.  As  shown  in  Figure  4.6. 1-1,  XCIAUs  filter  data 
between  DIS  nets. 
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Figure  4.6.1-1NSC  Networks 

A  conceptual  Fort  Riley  network  is  shown  in  Figure  4.6. 1-2.  There  is  no  connectivity 
between  the  Fort  Riley  BBS  Workstations  and  the  STOW-A  equipment. 
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Figure  4.6.1-2Fort  Riley  Network 

Figure  4.6. 1-3  provides  a  general  drawing  for  the  lOBaseT  and  Thicknet  networks  at 
AVTB  and  MWSTC.  XCIAUs  translate  between  SIMNET  and  DIS  protocols.  The  LRS 
simulators  in  the  MWTB  extension  are  not  portrayed.  Previous  LRS  network 
configurations  placed  the  LRS  systems  on  separate  lOBaseT  subnets  with  XCIAUs 
dedicated  to  limit  the  number  of  incoming  PDUs. 


Figure  4.6.1-3  Remote  Network  With  SIMNET  Simulators 
4.6.2  Wide  Area  Network 

Wide  Area  Network  communications  connect  all  remote  participants  with  the  central 
technical  control  hub  site.  The  Application  Gateway  function  serves  as  the  primary 
interface  between  local  and  remote  sites.  Each  participating  site  must  have  an 
Application  Gateway  and  access  to  the  DSI.  The  DSI  provides  the  long  haul 
communication  services. 
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4.6.2.1  Application  Gateway 

The  amount  of  packet  information  that  can  be  passed  through  a  Wide  Area  Network 
(WAN)  is  normally  more  restricted  than  the  amount  that  can  be  passed  through  a  local 
area  network  (LAN).  The  AG  uses  two  techniques  to  reduce  the  amount  of  traffic  that  is 
passed  on  a  WAN: 

1.  Load  Leveling.  Load  leveling  provides  flow  control  when  transmitting 
information  from  a  LAN  to  a  WAN.  When  information  is  received  by  the  AG 
which  exceed  a  certain  rate,  the  information  is  buffered  and  transmitted  over  a 
longer  period  of  time.  This  helps  prevent  lost  packets  by  reducing  the  load  on  the 
WAN. 

2.  Quiescence.  Quiescence  reduces  the  traffic  on  a  WAN  by  reducing  the  time  that 
updates  are  sent  over  the  WAN  for  entities  that  are  not  changing  state.  To  keep 
track  of  entities,  certain  DIS/SIMNET  applications  require  certain  update  rates. 
For  instance,  in  ModSAF,  vehicle  updates  for  even  stationary  vehicles  are  sent 
once  every  five  seconds.  To  insure  that  applications  get  the  needed  updates,  when 
an  AG  finds  a  entity  that  is  not  changing  state,  it  sends  a  Quiescence  PDU,  which 
identifies  all  quiescent  entities,  every  two  minutes.  The  AGs  on  both  LANs  then 
track  the  quiescence  entity.  While  the  entity  remains  in  quiescence  the  AG  on  the 
receiving  end  will  automatically  generate  the  entity  PDU  to  send  to  the 
applications  on  its  end. 

The  AG  hardware  platform  for  STOWEX  96  was  an  SGI  Indigo  2  R4400  running  IRIX 
5.3.  The  AG  uses  two  Ethernet  ports  in  order  to  transfer  data  between  the  local  area 
network  and  the  WAN  (DSI). 

4. 6. 2. 2  DSI 

The  DSI  is  a  multiprotocol  WAN  and  network  management  service  which  supports  a 
broad  range  of  warfighting  interoperability  activities.  The  primary  purpose  of  the  DSI  is 
to  provide  a  communications  pipeline  which  enables  physically  distributed  and  dissimilar 
virtual,  live  and  constructive  simulations  programs  to  interoperate  in  advanced 
warfighting  simulations.  It  supports  traffic  from  various  virtual  and  constructive 
simulation  sources  such  as  DIS,  SIMNET,  Corps  Battle  Simulation  (CBS),  BBS,  Air 
Warfare  Simulation  (AWSIM)  and  the  Aggregate  Level  Simulation  Protocol  (ALSP) 
Confederation.  The  DSI  also  serves  the  command  and  control  community  with  Video 
Teleconferencing  (VTC)  and  Distributed  Collaborative  Planning  (DCP).  The  DSI  has 
over  100  DoD  users  in  the  continental  United  States  (CONUS),  Europe,  Hawaii,  Japan 
and  Korea. 

The  DSI  is  composed  of  a  number  of  router  hub  sites  which  together  form  the  WAN 
backbone.  Each  of  the  hubs  are  multiply  connected  to  the  other  hub  sites.  User  sites  are 
connected  to  the  backbone  hubs  in  a  star  configuration.  The  user  sites  are  configured 
with  one  to  four  routers  and  associated  hardware  (i.e.,  gateway  and  Ethernet  boards)  each, 
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depending  on  user  requirements,  to  handle  classified  or  unclassified  data.  The  DSI 
employs  a  number  of  routing  protocols  including  Host  Access  Protocol  (HAP),  Internet 
Stream  Protocol  (ST-II),  Frame  Relay,  Open  Shortest  Path  First  (OSPF),  Exterior 
Gateway  Protocol  (EGP),  Shortest  Path  First  (SPF),  Internet  Protocol  (IP),  User 
Datagram  Protocol  (UDP),  Transmission  Control  Protocol  (TCP),  and  Internet  Stream 
Protocol  (SDP). 

The  network  configuration  used  for  STOWEX  96  is  shown  in  Figure  4.6.2.2-1.  Houston 
Associates,  Inc.  (HAI),  the  contractor  responsible  for  maintenance  of  the  DSI,  originally 
configured  each  site  except  the  ASC  with  dual  homing  capability,  or  having  a  primary 
and  a  secondary  DSI  connection  in  order  to  provide  automatic  backup  in  case  of  DSI 
failure.  This  configuration  was  only  partially  successful,  as  discussed  in  sections  5. 4. 2. 3 
and  5.4. 3. 3  of  this  document.  The  final  DSI  configuration  had  dual  homing  for  the  NSC, 
Fort  Riley  and  Fort  Knox.  Fort  Rucker  and  the  ASC  used  a  single  connection  since  one 
of  Fort  Rucker’s  connections  was  not  working,  and  the  ASC  did  not  have  the  equipment 
to  support  dual  homing. 


Simulation  Site  -  Primary  Site  Connection 

Secondary  Site  Connection 
DSI  Connection 


DSI  Hub  Site 


Figure  4.6.2.2-1  DSI  Configuration,  STOWEX  96 
4.6.3  Test  Support  Tools 

A  network  analysis  capability  should  be  provided  at  each  participating  STOWEX  site  in 
order  to  assess  network  traffic  loads  in  support  of  troubleshooting  functions. 

During  the  functional  testing,  entity  loading  data  was  manually  collected  for  each  of  the 
ModSAF  Farm  machines.  The  capability  to  collect  statistics  automatically  from 
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ModSAF  for  real-time  display  and  logging  would  provide  more  consistent  data  needed  to 
optimize  the  Farm  load  leveling  process  and  could  assist  in  the  identification  of 
performance  limitations. 

While  not  an  operational  necessity,  it  is  efficient  to  have  a  PVD  adjacent  to  the  manned 
simulator  used  during  test  for  technical  control  purposes.  During  integration  and  test 
periods,  a  PVD  provides  the  only  clear  method  to  communicate  scenario  information 
between  technical  control  personnel  and  manned  simulator  operators. 
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5.0  STOWEX  96 

The  following  section  summarizes  the  engineering  activities  of  the  STOWEX  96 
Delivery  Order,  including  the  engineering  planning,  architecture  development,  test  and 
integration,  exercise  support,  and  post  exercise  impressions. 

5.1  Planning  and  Analysis  Phase  Summary 

The  planning  activities  that  occurred  included  the  planning  and  scheduling  of  the 
technical  activities,  performing  site  surveys  of  the  STOWEX  96  sites,  establishing  and 
implementing  the  mapping  among  simulation  components,  and  providing  any  supporting 
equipment  needed  for  the  exercise. 

5.1.1  Site  Survey 

Site  surveys  were  performed  for  the  NSC,  the  BSC,  and  the  Fort  Knox  MWTB  and 
MWSTC  facilities.  A  site  survey  checklist  was  developed  prior  to  visiting  each  site.  An 
updated  list  is  provided  in  Appendix  B.  Key  elements  included: 

•  Space 

— NSC:  provide  space  for  the  STOWEX  infrastructure  hardware  and  technical 
control  personnel 

— Fort  Riley:  provide  space  for  STRIPES  and  technical  control  equipment  as 
required. 

•  Power 

— NSC:  provide  power  for  platforms  and  monitors  for  up  to  10  Farm  processors, 
an  OPSIN,  a  Farm  PVD,  2  STRIPES  2D  and  3D  suites,  4  XCIAUs,  a  data 
logger  and  peripherals,  an  AG 

— Fort  Riley:  provide  power  for  platforms  and  monitors  for  at  least  a  data  logger 
and  peripherals,  STRIPES  2D  and  3D,  an  XCIAU,  an  AG. 

— If  an  Onyx  is  procured  for  the  STRIPES  3D,  the  site  should  provide  220  power; 

•  Support  equipment  (tables,  racks,  special  stands  for  37”  monitors) 

•  Inter-  intra-  building  communication  (data,  voice)  capability 
— type  (including  ability  to  dial  long  distance) 

— number 

— location,  including  proximity  to  equipment:  technical  control  equipment  should 
be  co-located  in  order  to  reduce  the  number  of  technical  control  personnel 
needed  per  site. 

•  Site  access 

— NSC  required  visitor  requests/clearances 

— Fort  Riley,  Fort  Rucker,  and  Fort  Knox:  no  visitor  clearances  required 
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The  site  surveys  determined  that  there  was  sufficient  power  for  the  equipment  to  be  added 
to  both  the  NSC  and  Fort  Riley.  The  Onyx  procured  for  the  NSC  was  configured  with 
110  power  and  did  not  require  additional  220  source  to  be  added  to  either  of  the 
STOWEX  rooms.  However,  the  Onyx  does  need  to  be  reconfigured  for  220  power.  This 
will  require  NSC  to  provide  a  220  power  source  for  future  utilization.  Commercial 
telephone  lines  were  added  to  both  the  NSC  and  Fort  Riley  in  support  of  exercise  control 
and  technical  control  voice  communication  needs. 

5.1.2  Mapping 

In  order  to  ensure  interoperability  among  all  of  the  simulations  and  simulators,  terrain 
and  entity  databases  used  by  the  various  simulations  were  mapped.  For  STOWEX  96, 
these  simulations  consisted  of: 

•  BBS 

•  ModSAF 

•  STRIPES 

•  SIMNET  manned  simulators  (Ml,  M2,  RWA,  Stealth) 

•  DIS  LRS  manned  simulators  (ARSI,  RCVS,  Dial-a-Tank) 

Terrain  interoperability  is  required  in  order  to  ensure  accurate  x-,  y-,  and  z-  coordinate 
locations  of  vehicles  and  terrain  features  within  the  simulation,  and  equivalent 
perceptions  with  respect  to  detectability,  cover,  concealment  and  line-of-sight  between 
manned  simulators  and  computer  generated  forces.  For  STOWEX  96,  all  simulations  and 
simulators  used  the  “large”  NTC  terrain  database,  denoted  as  “0101.” 

Appendix  C  provides  a  summary  of  the  mapping  efforts  involved  with  the  SIMNET 
dynamic  element  database  (DED)  and  contains  the  mapping  tables  of  vehicle  types  and 
weapon  systems/ammunition. 

5.1.3  Communications  Support 

STOWEX  96  required  three  types  of  non-digital  communications:  commercial  voice 
networks  for  exercise  and  technical  control,  video  teleconferencing,  and  tactical 
communications  capability  among  the  exercise  participants  at  Fort  Riley,  Fort  Knox,  and 
Fort  Rucker. 

Site  capabilities  for  video  conferencing  and  commercial  voice  telephone  lines  for  inter¬ 
site  exercise  control  and  technical  control  communication  were  used.  As  a  result  of  the 
PW95  Alpha  and  Beta  Test  experience,  existing  DSN  capability  at  Fort  Riley  and  the 
NSC  were  augmented  with  commercial  telephone  lines.  Ten-way  conferencing  for  both 
the  Technical  and  Exercise  Control  networks  was  coordinated  with  the  NSC  DOIM  for 
the  training  exercise.  Daily  conference  calls  throughout  the  test  /  integration  phases  and 
during  the  exercise  were  established  by  Technical  Control  personnel  at  NSC  utilized 
commercial  telephone  lines.  Diagrams  of  the  networks,  conference  call  instructions,  and 
a  telephone  directory  are  contained  in  the  Communication  User’s  Guide  in  Appendix  D. 
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For  STOWEX  96,  meetings,  rehearsals  and  the  first  AAR  were  conducted  via  VTC 
between  Fort  Riley  and  Fort  Knox.  The  VTC  was  performed  utilizing  the  DSI  “Dual 
Homing”  feature  to  provide  real-time  VTC  simultaneously  with  the  training  exercise  data 
streams.  This  approach  contrast  with  the  Prairie  Warrior  95  which  required  that  data 
streams  generated  by  the  training  exercise  be  brought  down  by  HAI  and  VTC  streams 
subsequently  established.  More  extensive  use  of  video  teleconferencing  with  all 
participating  sites  was  originally  planned  but  was  limited  by  lack  dual  homing  capability 
at  Fort  Rucker  and  the  Army  Simulation  Center  (ASC).  Additional  VTC  information, 
original  VTC  schedules  and  moderator  check-list  is  contained  in  the  Communication 
User’s  Guide  in  Appendix  D. 

The  STOWEX  96  implemented  tactical  communication  networks  which  simulated  the 
Command  network,  the  Administrative  and  Logistics  (A&L)  network,  the  Operational 
and  Intelligence  (O&I)  network,  and  Fire  Support  (FS)  network.  A  fifth  network  for  the 
Fire  Support  Digital  network  was  planned  but  not  implemented  due  to  difficulties 
encountered  by  the  Department  of  Information  Management  (DOIM)  in  interfacing  the 
Tactical  Terminal  Adapter  and  the  Secure  Telephone  Unit  (STU)  required  for  secure 
transmissions. 

Network  bubble  diagrams  for  each  of  the  tactical  networks  are  provided  in  the 
Communication  User’s  guide  in  Appendix  D.  The  overview  diagram  of  the  Command 
radio  /  telephone  network  is  shown  in  Figure  5. 1.3-1.  A  more  detailed  radio  /  telephone 
interface  diagram  is  contained  in  Appendix  D. 
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Figure  5.1.3-1  Command  Net 


The  RT-31  Tone  Remote  and  TP-8  Tone  Termination  Panel  provided  remote  control  of 
the  two-way  FM  radio  over  commercial  telephone  lines.  The  RT-31  generated  a  tone 
when  pushed-to-talk  that  keyed  the  radio  transmitter.  The  TP-8  decoded  the  tones  and 
provided  the  direct  interface  with  the  FM  radio.  The  specific  radio  frequency  used  was 
dictated  by  the  FM  radio  transceiver.  The  RT-31  also  provided  the  capability  to  monitor 
network  communication  via  the  built  in  speaker  and  provided  a  handset  with  a  push-to- 
talk  switch.  This  approach  provided  a  more  realistic  interface  to  tactical  communications 
than  the  previous  approach  of  using  commercial  speaker  phones  between  sites.  RT-31 
User’s  Instructions  are  provided  in  the  Communication  User’s  Guide,  Appendix  D. 

5.2  Exercise  Design  and  Development  Phase  Summary 

The  engineering  activities  that  supported  the  STOWEX  96  exercise  design  and 
development  phase  consisted  of  (1)  defining  and  coordinating  basic  interoperability 
issues,  (2)  establishing  the  system  architecture  and  STOW-A  hardware  infrastructure  for 
the  NSC  hub  and  each  remote  site,  identifying  the  configurations  of  Commercial-off-the- 
Shelf  (COTS)  and  GFE  software,  and  (3)  identifying  and  implementing  necessary 
modifications  of  BBS-ModSAF  linkage  and  technical  control  software  components. 
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The  DIS  protocol  to  be  followed  during  the  STOWEX  96  was  DIS  Draft  Standard 
Version  2.0.3.  The  terrain  for  the  STOWEX  96  was  the  NTC  “0101”  database.  The 
brigade  level  exercise  for  STOWEX  96  expected  to  produce  approximately  300-400 
virtual  entities;  however,  the  design  goal  for  the  BBS-ModSAF  linkage  was  to  process  a 
peak  of  500  virtual  entities  on  the  local  Farm  without  causing  a  system  crash. 

Figure  5.2-1  presents  a  top  level  system  diagram  depicting  the  STOWEX  96  at  NSC  and 
BSC.  Forts  Knox  and  Rucker  had  an  AG  and  XCIAU  but  no  STRIPES.  ASC  was 
configured  similarly  to  BSC. 


Fort  Riley  NSC 

BBS  Workstations  ppc 


Figure  5.2-1  STOWEX  System  Diagram 

The  primary  requirement  was  to  support  the  training  objectives  of  the  lsl  Infantry 
Division  (1ID).  One  of  the  keys  to  meeting  this  requirement  was  the  proper  sizing  of  the 
ModSAF  Farm.  Although  an  exercise  directive,  which  would  have  defined  the  task  force 
size,  was  not  available  early  in  the  program,  it  was  anticipated  that  the  Farm  would  need 
to  support  300-400  entities  which  was  well  within  the  500  entity  goal.  Based  on  PW  95 
experience  using  R4400s  and  IRIX  5.3  and  the  more  than  two-fold  improvement  in 
throughput  that  was  expected  to  be  gained  by  using  R1 0000s  and  IRIX  6.2,  it  was  agreed 
that  eight  back-ends  would  be  sufficient  to  support  the  training  exercise. 

Site  diagrams  containing  LAN  architecture,  workstation  type,  and  workstation  system 
function  (AG,  XCIAU,  Logger,  etc.)  were  the  primary  mechanism  for  defining  the  system 
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design.  Design  and  program  reviews  were  conducted  and,  with  STRICOM  concurrence, 
system  requirements  and  design  changes  were  made.  Changes  to  the  baseline  system 
design  included: 

•  Addition  of  the  ASC  view-port; 

•  Final  configuration  of  ModSAF  workstations  for  Fort  Knox  and  Fort  Rucker; 

•  Increased  number  of  SIMNET  simulators  at  Fort  Knox; 

•  Addition  of  ModSAF  workstation  at  NSC  to  play  OPFOR  air; 

•  New  hardware  implementation  for  tactical  communication  based  on  tone  remote 
technology; 

•  Addition  of  BBS  workstation  for  AAR  support; 

•  Reconfiguration  of  the  Fort  Knox  Blue  ModSAF; 

•  Addition  of  a  STRIPES  extension  monitor; 

Figures  5.2-2  through  5.2-7  provide  the  resulting  STOWEX  96  architecture  diagrams  by 
site.  Note  that  at  the  ASC  (Figure  5.2-7),  STRIPES  was  hosted  on  an  Onyx  that  was 
loaned  to  STOWEX  by  SGI.  This  Onyx  was  replaced  by  a  Maximum  Impact  after  the 
Exercise. 
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-NSC 


Figure  5.2-2  Fort  Riley  System  Diagram 
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Figure  5.2-3  National  Simulation  System  Diagram,  Technical  Control 
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to  XCIAU 
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Figure  5.2-4  National  Simulation  System  Diagram,  Visitor  Center 
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Figure  5.2-5  Fort  Knox  System  Diagram 
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Figure  5.2-7  Pentagon  System  Diagram 


The  manned  simulators  at  Fort  Knox  were  part  of  a  Task  Force  that  was  augmented  by 
blue  forces  in  ModSAF.  The  original  plan  for  these  ModSAF  forces  utilized  the 
Observer  Controller  Stations  in  the  MWSTC  with  allocations  described  in  Table  5.2-1. 
Each  of  these  OCSs  have  older  SGI  hardware  (Indigo  and  Indy  computers)  that  have  been 
sufficient  for  older  versions  of  ModSAF.  Prior  to  the  final  integration  and  test,  at  the 
request  of  the  STOWEX  team,  the  Force  XXI  Training  Program  (FXXITP)  Contractor  at 
Fort  Knox  configured  newer  FXXITP  SGI  Indigo2  200Mhz  R4400  processors  augmented 
by  MWTB  assets,  and  used  the  resulting  suites  in  lieu  of  the  MWSTC  OCSs.  This  was 
requested  as  a  risk  mitigator  to  reduce  the  potential  for  ModSAF  system  problems  due  to 
overload  caused  by  the  increased  exercise  size  and  requirements  anticipated  with 
STOWEX. 
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Table  5.2-1  STOWEX  96  Fort  Knox  Blue  ModSAF  OCS  Configuration 


Station 

Number 

Station 

Function 

Entity 

Count 

Configuration 

OCS  1 

OPFOR 

No  changes 

A  Company 

5-25 

Pocket  (1  machine  as  front  end  and  back 
end),  1  logger 

OCS  3 

EN/ADA 

40 

1  front  end,  1  back  end 

OCS  4 

B  Company 

5-25 

Pocket  (1  machine  as  front  end  and  back 
end),  1  logger 

OCS  5 

CSS 

40 

Pocket  (1  machine  as  front  end  and  back 
end) 

OCS  6 

MTR 

10 

Pocket  (1  machine  as  front  end  and  back 
end) 

OCS  7 

SR  O/C 

1  front  end,  1  logger 

OCS  8 

C  Company 

5-25 

1  front  end,  1  back  end,  1  logger 

OCS  9 

EXCON 

150  (night) 

2  front  ends,  2  back  ends 

OCS  10 

D  Company 

5-25 

1  front  end,  1  back  end,  logger 

OCS  11 

(none 

identified) 

OCS  12 

Scouts 

12 

Pocket  (1  machine  as  front  end  and  back 
end),  1  logger 

The  final  Blue  ModSAF  configuration  used  Indigos  for  loggers.  All  other  machines  were 
Indigo2  with  the  exception  of  the  Mortar  front  end  and  the  Scouts  front  end  which  were 
Indys. 


5.3  Procurement  and  Equipment  Shipment  Planning 

The  equipment  identified  in  the  STOWEX  96  Bill  of  Material  (BOM)  was  provided  to 
the  buyer  who,  by  procedure,  solicited  multiple  quotes  to  identify  low  bidders  where 
appropriate.  When  equipment  was  received,  it  was  logged  and  checked  out  to 
Engineering,  set  up  in  the  OSF  and  used  in  Integration  and  Test. 

The  requirements  for  STOWEX  96  shipping  included  the  identification  of  hardware  and 
software  configuration  of  each  component,  utilizing  the  Configuration  Management 
organization.  A  safe,  timely  and  cost  effective  method  of  shipment  was  identified  to 
support  both  OSF  integration  schedules  and  site  test  schedules.  Land  carrier  was  selected 
for  the  NSC  and  BSC  delivery  due  to  the  amount  of  equipment;  air  freight  was  used  for 
Fort  Knox,  Fort  Rucker,  and  ASC.  No  special  precautions  for  computer  information 
security  was  required  since  STOWEX  96  is  not  classified.  When  equipment  availability 
has  the  potential  to  impact  schedule,  expediting  methods  of  priority  shipment  and  drop 
shipment  to  site  were  employed. 
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Spares  were  shipped  in  order  to  provide  uninterrupted  exercise  support.  These  spares 
included  CPUs  (box  level  replacement),  memory  and  dual  Ethernet  cards  (internal 
component/board  level  replacement),  peripherals  (cables,  hubs,  storage  devices),  and  site 
assets  or  resources  (available  power,  types  of  power). 

Appendix  E  provides  the  tables  identifying  the  destination  of  equipment  received  in  the 
OSF  as  well  as  tag  numbers,  function,  and  configuration.  Appendix  E  also  provides 
figures  used  in  the  shipping  planning  that  demonstrate  how  the  shipping  lists  were 
derived  from  the  architecture  drawings.  These  figures  do  not  reflect  the  post  exercise 
reallocations.  The  shading  of  the  Sound  Storm  indicated  that  this  component  had  to  be 
shipped  to  the  sites  directly  by  the  vendor.  The  shipping  addresses  are  provided  in 
Appendix  E.  For  the  Pentagon,  it  was  recommended  that  items  be  shipped  to  the 
Lockheed  Martin  facility  since  a  Pentagon  address  adds  an  additional  day  to  the  timeline. 

Fort  Knox  and  Fort  Rucker  had  sufficient  ADST  GFE  simulation  equipment  to  support 
STOWEX  96.  Much  of  ASC  equipment  was  provided  as  GFE  or  supported  by  assets 
loaned  by  Silicon  Graphics.  Additional  support  equipment,  primarily  for  both  voice  and 
tactical  communications  was  shipped  to  Fort  Knox  and  Fort  Rucker  via  overnight  air. 

5.4  Integration  and  Test  Phase  Summary 

The  Test  Phase  prior  to  the  STOWEX  96  Exercise  was  divided  into  three  periods:  the 
Operational  Support  Facility  (OSF)  Integration  and  Test  (I&T),  Functional  Test  1  (FT1), 
and  Functional  Test  2  (FT2).  The  fundamental  objectives  of  each  period  were  the  same: 

1 .  To  ensure  that  the  STOW-A  1 .5  Simulation  subsystems  including  BBS,  ModSAF, 
OPSIN,  XCIAU,  AG,  and  STRIPES  would  support  the  STOWEX  96  exercise 
conducted  in  September  1996, 

2.  To  disclose  latent  deficiencies  of  the  system  to  the  customer  and  to  propose  work¬ 
around  solutions  for  those  deficiencies  prior  to  the  exercise, 

3.  To  provide  a  systematic  approach  to  validate  the  development  and  integration  of 
STOW-A  1 .5  Simulation  sub-systems,  and 

4.  To  rehearse  initialization,  troubleshooting,  restart,  and  shutdown  procedures  to  be 
used  in  the  STOWEX  96  exercise. 

An  additional  objective  of  the  Test  Phase  was  to  develop  a  series  of  structured  test 
procedures  that  could  be  used  in  conjunction  with  future  STOW-A  exercises.  These  test 
procedures  were  used  both  at  the  OSF  and  at  the  sites  to  test  system  stability,  system 
integration,  and  to  verify  the  correction  of  PW95  deficiencies  and  performance 
enhancements  in  the  STOW-A  1 .5  baseline.  Appendix  F  contains  specific  test  procedures 
that  were  executed.  This  approach  ensured  that  appropriate  actions  were  being  input  by 
the  system  operators  and  the  results  were  observed  and  documented. 
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OSF  I&T  and  FT1  were  performed  in  testing  environments  designed  to  support  specific 
test  objectives;  FT2  was  performed  in  a  fully  operational  environment. 

In  spite  of  initial  schedule  delays  and  some  recurring  software  and  DSI  network 
problems,  objectives  for  each  of  the  test  periods  were  met  and  the  test  period  was 
successful. 

5.4.1  OSF 

5.4.1. 1  Objectives 

The  OSF  I&T  was  scheduled  for  performance  at  the  OSF  in  Orlando,  FL,  from  1  July 
through  8  August  1996.  Integration  was  scheduled  from  1  July  through  21  July  and  Test 
was  scheduled  from  22  July  through  8  August. 

During  the  Integration  phase,  integration  and  test  personnel  installed  and  checked  out 
hardware  and  system  software,  test  new  software  capabilities  and  incorporated  required 
modifications.  The  Test  phase  was  to  be  a  structured  dry  run  of  the  individual  test  cases 
that  were  to  be  performed  during  FT1  and  FT2. 

The  initial  objective  of  this  period  was  to  set  up  and  configure  the  hardware  and  the 
system  suite.  Memory,  harddrives,  and  Ethernet  cards  were  added  to  the  SGI  computers. 
Compilers  and  software  drivers  for  the  Ethernet  cards  were  loaded  and  checked  out. 
Oracle  was  loaded  onto  the  R 10000s  that  were  designated  as  the  STRIPES  2D  machines. 
The  hardware  and  software  configurations  were  identified  on  system  diagrams,  on 
machine  tags,  and  confirmed  with  Configuration  Management.  Machines  designated  for 
OPSIN/ModSAF  were  configured  with  256  MB  of  memory  and  the  swap  space  was 
changed  accordingly.  Once  the  configurations  were  completed,  the  hardware  was 
checked  out.  Systems  were  preloaded  with  the  appropriate  application  software,  and  the 
machines  were  functionally  configured  and  identified  for  the  specific  applications  such  as 
STRIPES,  XCIAU-1,  XCIAU-2,  and  AG.  Once  this  was  accomplished,  hardware 
performance  and  stability  were  tested. 

An  additional  objective  was  to  test  local  system  stability.  The  system  was  assembled  in 
the  target  system  configuration.  Wherever  possible,  target  hardware  performed  in  its 
exercise  usage.  This  provided  actual  experience  with  the  new  hardware.  The  only 
software  changes  allowed  during  this  stage  were  those  aimed  at  fixing  catastrophic 
problems,  and  low-risk  fixes  to  known  deficiencies. 

Two  major  issues  were  identified  during  the  OSF  integration  period.  First,  three  of  the 
machines  failed  within  the  first  two  weeks.  Equipment  that  had  been  designated  for  the 
OSF  was  shipped  instead  to  the  NSC  as  spares.  Second,  the  new  machines  came  with  a 
new  operating  system,  IRIX  6.2,  and  it  was  soon  determined  that  there  were  problems 
with  software  that  had  been  compiled  under  IRIX  5.3. 
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5.4.1.2  Test  Suite  Configuration 

The  Test  Suite  Configuration  used  for  the  OSF  I&T  is  given  in  Figure  5.4.1.2-1  OSF 
System  Configuration  Diagram,  Integration  and  Test. 
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Figure  5.4.1.2-1  OSF  System  Configuration  Diagram,  Integration  and  Test 
5.4.1.3  Events  Summary 

The  Schedule  for  the  OSF  I&T  needed  to  be  compressed  due  to  late  receipt  of  system 
hardware  from  vendors.  This  necessitated  running  the  Integration  and  Test  Phases 
simultaneously  over  the  course  of  six  days.  The  planned  date  for  shipping  hardware  to 
the  field  sites  was  still  maintained  and  the  impact  of  the  schedule  delay  to  the  overall  test 
program  was  minimal. 

Some  of  the  hardware  was  shipped  directly  to  the  field  sites  and  could  not  be  tested  prior 
to  site  installation.  This  hardware  included  Sound  Storms,  RT-31s/TP-8s,  and  some 
replacement  and  loaner  SGI  machines.  In  addition,  the  scope  of  the  I&T  activities  was 
further  limited  by  the  unavailability  of  the  Ml  and  RWA  SIMNET  simulators.  Much  of 
the  mapping  and  other  tests  utilizing  the  simulators  planned  for  I&T  needed  to  be 
deferred  to  FT1 . 

The  System  Stability  Test  and  System  Integration  Test  were  expanded  and  procedures  for 
individual  test  cases  were  corrected  or  augmented  as  required.  An  initial  set  of 
procedures  for  system  Start,  Restart,  and  Shutdown  was  written  and  tested  against  the 
local  system. 
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The  local  OSF  STOW-A  system  was  determined  to  be  stable.  No  system  crashes  were 
reported  with  the  exception  of  a  repeatable  crash  of  the  STRIPES  3D  when  the  Log 
Playback  function  was  invoked.  This  problem  was  reported  and  corrected  in  a 
subsequent  release  of  STRIPES  software. 

The  results  of  individual  deficiency-related  test  cases  varied:  several  known  deficiencies 
had  not  been  fixed,  to  include  disaggregated  FWA  and  RWA  movement  problems,  and 
mapping  inconsistencies.  Test  activities  were  formally  logged  and  are  presented  in 
Appendix  G. 

5.4.2  FT  1 

5.4.2.1  Objectives 

FT1  was  scheduled  to  be  conducted  at  the  National  Simulation  Center  (NSC)  in  Fort 
Leavenworth,  KS  from  12-19  August  1996.  The  NSC  provided  the  Simulation 
Infrastructure  (STOW-A  System  and  MicroVAX  Farm  for  BBS),  and  a  limited  number  of 
technical  and  operational  personnel.  NSC  staff,  augmentees  and  contractor  personnel 
from  the  ADST II  team  supported  this  test. 

The  main  objectives  of  this  phase  were  as  listed  in  section  5.4.  Additional  objectives 
included: 

1.  Verification  of  the  functionality  and  hardware  configuration  of  the  STOW-A 
system  installed  at  the  NSC  to  include  the  core  suite,  the  upgraded  ModSAF 
Farm,  Technical  Control  (Stealth  CPU  &  Monitors,  Sound  Storm),  and  Visitor 
Center  (Stealth  CPU  &  Monitors,  Sound  Storm,  STRIPES), 

2.  Providing  a  systematic  approach  to  validate  the  local  integrity  and  stability  of  the 
STOW-A  1 .5  Simulation  sub-systems  at  the  NSC, 

3.  Providing  a  systematic  approach  to  validate  the  long  haul  connectivity  of  the 
STOW-A  1 .5  Simulation  sub-systems, 

4.  Rehearsal  of  the  STOWEX  96  exercise  scenario  at  a  single  site,  and 

5.  Verification  of  the  ModSAF  Farm’s  ability  to  handle  an  expected  exercise  load  of 
approximately  500  local  entities. 

Validation  of  long  haul  connectivity  necessitated  involvement  from  all  sites  that  were  to 
participate  in  the  STOWEX  96  exercise:  Fort  Riley,  Fort  Rucker,  Fort  Knox  and  the 
Pentagon,  as  well  as  the  NSC. 

The  only  software  changes  to  be  made  following  FT1  were  those  aimed  at  fixing 
catastrophic  problems. 
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5.4.2.2  Test  Suite  Configuration 

The  Test  Suite  at  the  start  of  FT1  was  located  solely  at  the  NSC.  The  configuration  used 
for  that  period  is  given  in  Figure  5.4.2.2-1  NSC  System  Configuration  Diagram, 
Functional  Test  1 .  Some  equipment,  including  the  Stealth  Onyx  and  the  OPSIN  R4400 
were  replaced  or  shipped  to  other  locations  in  order  to  meet  the  required  exercise 
configuration.  By  the  end  of  FT1  the  test  environment  was  the  same  as  that  used  in  the 
exercise.  Facilities  and  equipment  diagrams  for  the  exercise  configuration  are  given  in 
Section  5.1. 


Figure  5.4.2.2-1  NSC  System  Configuration  Diagram,  Functional  Test  1 
S.4.2.3  Events  Summary 

The  scheduled  start  of  FT1  was  delayed  by  two  days  in  order  to  accommodate  equipment 
shipping  and  setup.  FT1  was  started  on  14  August  and  finished  on  21  August  1996. 

The  following  tasks  were  completed: 

1 .  Hardware  and  Software  configurations  for  FT1  were  documented  for  test. 

2.  Startup,  Restart,  and  Shutdown  procedures  were  expanded,  corrected  and 
formalized;  input  from  NSC  personnel  was  solicited  and  incorporated. 

3.  The  System  Integration  Test  Procedure  was  expanded,  successfully  run,  and 
documented.  IP  addresses  for  all  sites  were  documented  for  testing  purposes. 
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4.  Procedures  for  the  System  Stability  Test,  as  described  on  page  43  and  in 
Appendix  F.  -were  completed;  the  test  was  run  daily  and  following  each  software 
modification. 

5.  The  Long  Haul  Connectivity  Test  was  successfully  run  and  documented  to  ensure 
connectivity  between  sites. 

6.  Mapping  tests  were  run,  including  comparison  tests  of  OPSTATE  to  task  frames, 
3D  models,  and  munitions.  These  tests  were  run  at  the  NSC  and  between  sites. 
Fixes  for  3D  visual  mapping  were  accomplished  in  real  time  for  the  simulators 
and  the  Stealth.  These  fixes  were  intended  to  provided  correlation  between  the 
simulator,  Stealth  visuals,  and  the  BBS  vehicle  types. 

7.  A  test  of  the  SoundStorm  was  run  and  documented  in  the  test  log  to  ensure  correct 
battle  sound  effects. 

8.  A  dead  hulk  test  case  was  run  and  documented  in  the  test  log. 

9.  The  OPSIN  hardware  was  upgraded  from  an  R4400  to  an  R10000  with  a  Qualix 
Ethernet  card.  OPSIN  and  ModSAF  fixes  were  incorporated  to  increase  system 
stability.  OPSIN  was  recompiled  for  IRIX  6.2. 

10.  LRS  vehicles  at  Fort  Knox  were  added  to  the  exercise  plan.  Test  cases  for 
specific  LRS  vehicles  were  designed  and  run  in  order  to  see  if  the  presence  of 
these  vehicles  would  adversely  impact  the  system. 

1 1 .  Load  testing  with  artillery  firing  and  full  tactical  maneuver  and  engagements 
achieved  loads  in  excess  of  600  local  Farm  vehicle  entities,  700  total  vehicle 
entities,  and  1200  total  aggregated/disaggregated  entities. 

FT1  experienced  a  series  of  ModSAF  Farm  crashes  and  disaggregation  anomalies,  such 
as  disaggregating  vehicles  “disappearing”  from  the  Farm.  Much  time  was  spent  trying  to 
diagnose  the  cause  of  these  problems.  The  problems  were  traced  to  an  unreliable  IRIX 
6.2  ModSAF  compilation.  ModSAF  was  recompiled  to  an  IRIX  5.3  executable,  which 
significantly  improved  system  performance  and  virtually  eliminated  the  Farm  crashes  and 
disaggregation  anomalies. 

A  software  change  incorporating  a  dead  hulks  “fix”  was  unsuccessfully  tested.  The 
purpose  of  this  fix  was  to  remove  dead  hulks  from  the  playing  board  in  order  to  reduce 
system  load.  The  ModSAF  recompile  improved  system  performance  enough  that 
pursuing  the  dead  hulks  matter  was  dropped. 

The  importance  of  establishing  and  maintaining  a  structured  set  of  Start,  Restart  and 
Shutdown  procedures,  and  developing  a  set  of  system  rules  and  constraints  that  could  be 
used  at  all  sites  was  emphasized  when  failure  to  follow  existing  procedures  resulted  in 
improper  initializations  and  errors  on  restart.  These  procedures  and  rules  continued  to 
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evolve  and  became  the  Technical  Control  Document,  reproduced  in  Appendix  H  of  this 
document. 

The  testing  of  minefields  identified  the  following: 

•  Mine  placement  in  the  minefields  was  too  sparse  to  be  effective; 

•  Workarounds  to  increase  the  mine  density  and  to  provide  breaching  methods  did 
not  provide  a  good  solution. 

Although  initially  there  were  no  apparent  BBS  to  ModSAF  mapping  problems,  mapping 
discrepancies  between  the  BBS,  the  Stealth  and  the  simulators  were  revealed.  AcuSoft 
indicated  in  a  teleconference  that  mapping  problems  were  due  in  part  to  the  use  of  an  old 
mapping  table  (an  AcuSoft  configuration  management  problem).  Changes  were  faxed 
and  incorporated.  Additional  changes  to  the  mapping  files  were  made  as  deemed 
necessary.  Once  the  problems  were  identified  and  fixes  were  made  the  system  appeared 
to  become  significantly  more  stable. 

The  local  NSC  environment  was  healthy  enough  to  bring  the  other  sites  into  the  test 
environment  earlier  and  more  fully  at  this  stage  than  anticipated.  The  Long  Haul 
Connectivity  Test  was  finalized  and  successfully  run.  SIMNET  vehicles  were  introduced 
in  a  limited  capacity  to  the  system.  Their  presence  did  not  adversely  impact  the  system, 
except  when  they  were  initialized  in  locations  that  forced  instant  disaggregation  of 
numerous  BBS  units. 

The  DSI  links  caused  serious  problems  from  the  end  of  FT1  through  the  middle  of  FT2, 
and  to  lesser  a  extent  throughout  the  remainder  of  the  test  period.  Some  of  the  sites, 
particularly  Fort  Rucker  and  Fort  Riley,  could  not  see  all  (and  sometimes  any)  of  the 
remote  vehicles.  Initial  stream  sizes  were  incorrectly  set  by  HAI,  and  later  reset  to  too 
low  a  bandwidth.  Eventually  HAI  found  the  following  configuration  to  be  successful: 


NSC: 

(200  b  * 

200  pps 

*  8) 

/  1024 

=  312  Kbs 

AVTB: 

(200  b  * 

200  pps 

*  8) 

/ 1024  = 

=  312  Kbs 

MWTB: 

(200  b  * 

200  pps 

*  8) 

/  1 024 

=  312  Kbs 

ASC: 

(200  b  * 

90  pps  * 

8)/ 

1024  = 

141  Kbs 

BSC: 

(200  b  * 

90  pps  * 

8)/ 

1024  = 

141  Kbs 

where  the  first  number  is  the  packet  size,  the  second  is  the  packets  per  second,  8  and  1 024 
are  conversion  factors  and  the  answer  is  the  allotted  bandwidth.  Total  bandwidth  for  the 
system  was  1 .22  Mbs. 

In  addition,  HAI  originally  configured  each  site  with  dual  homing  capability,  as  having  a 
primary  and  a  secondary  DSI  connection  in  order  to  provide  automatic  backup  in  case  of 
DSI  failure.  Much  discussion  and  many  trial  and  error  solutions  were  attempted  as  DSI 
connections  continuously  went  down.  It  became  evident  that  Fort  Rucker’s  connection 


46 


ADST-II-CDRL-0 1 3R-9600220-B  A 

1 8  December§-Qetober  1996 


through  Scott  did  not  work;  once  it  was  eliminated  from  the  routing,  the  communications 
were  successful. 

5.4.3  FT  2 

5.4.3.1  Objectives 

FT2  was  scheduled  to  be  conducted  from  20-30  August  1996.  All  sites  involved  in  the 
exercise  were  scheduled  to  be  involved  in  FT2,  including  the  NSC,  the  Battle  Simulation 
Center  (BSC),  Fort  Riley,  Kansas,  the  MWSTC  and  the  MWTB,  Fort  Knox,  Kentucky, 
the  AVTB,  Fort  Rucker,  Alabama,  and  the  ASC  at  the  Pentagon. 

The  main  objectives  of  this  phase  were  as  listed  in  section  5.4.  Additional  objectives 
included: 

1.  Verification  of  the  STOWEX  systems  functionality  at  the  exercise  control  site 
(Fort  Riley),  at  the  SIMNET  sites  (Fort  Knox  and  Fort  Rucker),  and  at  the  ASC 
viewport. 

2.  Validation  of  the  long  haul  integrity  and  stability  of  the  STOW-A  1.5  simulation 
sub-systems. 

3.  Verification  of  communication  systems  (radio,  tone/panel  &  remotes,  speaker 
phones). 

4.  To  dry  run  a  test  scenario  that  would  stress  the  system  in  manner  similar  to  that  of 
the  STOWEX  96  exercise  as  defined  by  1st  Infantry  Division  (Ml  Exercise 
Directive  for  1st  Bde  Combat  Team  (TBCT)  BBS  (STOWEX1  Command  Post 
Exercise  DEVIL  WARRIOR  96-19,  3-6  September  1996. 

5.4.3.2  Test  Suite  Configuration 

Facilities  diagrams  and  equipment  used  for  FT2  and  provided  in  Section  5.1  are  the  same 
as  those  used  in  the  exercise. 

5.4.3.3  Events  Summary 

FT2  was  started  on  22  August  and  ran  through  27  August  and  from  29  August  through  2 
September  1996.  On  28  August  the  system  was  given  to  the  customer  for  their  dry  run  of 
the  exercise  scenario.  Primary  emphasis  was  placed  on  running  a  scenarios  as  close  to 
the  actual  exercise  scenario  as  possible  in  the  exercise  environment  in  order  to  validate 
the  system  for  the  exercise.  The  System  Stability  Test  with  an  expanded  scenario  was 
used  for  this  purpose. 
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The  following  tasks  were  completed: 

1 .  Hardware  and  Software  configurations  for  FT2  were  finalized  and  documented  for 
test. 

2.  Startup,  Restart,  and  Shutdown  procedures  were  finalized,  tested  and  validated. 

3.  Tactical  Communications  of  RT-3 1  and  TP-8  equipment  was  tested. 

4.  System  Stability  Test  was  run  on  a  daily  basis  in  accordance  with  the  Test  Plan 
and  Procedures. 

5.  Workarounds  were  tested  for  bypassing  minefields  problems. 

6.  Mapping  issues  were  resolved. 

7.  DSI  problems  were  resolved. 

The  location  of  BBS  HICON  was  changed  from  NSC  to  Fort  Riley.  NSC  retained  the 
BBS  See  All  station  and  functioned  as  Technical  Control.  Late  in  FT2  control  of  blue 
ModSAF  was  shifted  from  NSC  to  the  Fort  Knox  T-site. 

Problems  with  the  DSI  seriously  impacted  the  progress  of  FT2.  These  problems  are 
addressed  in  section  5. 3.2. 2.  Some  of  the  contractor  test  activities,  including  stability 
testing  of  area  defense  and  offense  and  transition  from  recon  to  counter-recon,  could  not 
be  performed  prior  to  turning  the  test  over  to  the  customer.  Also,  DSI  network 
configurations  were  often  changed  overnight  and  the  new  configurations  would  not 
support  testing  in  the  morning.  The  final  DSI  configuration  had  dual  homing  for  the 
NSC,  Fort  Riley  and  Fort  Knox.  Fort  Rucker  and  the  ASC  used  a  single  connection 
(note:  ASC  did  not  have  the  equipment  to  support  dual  homing).  Final  stream  size  and 
bandwidth  configuration  are  noted  in  section  5.4.2.2. 

System  Stability  testing  was  performed  to  determine  if  the  system  and  in  particular,  the 
ModSAF  Farm,  would  be  stable  (would  not  crash)  under  exercise  conditions.  The 
stability  testing  was  performed  in  a  series  of  test  using  pre-defined  scenarios  developed 
by  NSC  personnel.  The  scenarios  provided  for  blue  defense  against  the  controlled 
engagement  by  red  forces.  The  total  number  of  red  force  vehicles  in  each  attack  wave, 
the  number  of  waves,  and  time  between  the  attacking  red  force  waves  were  altered  (either 
by  running  different  scenarios  or  by  modifying  a  scenario  extemporaneously)  to  gradually 
increase  the  stress  (number  of  entities)  to  the  system.  Blue  units  were  inserted  to  create 
spikes  in  the  number  of  red  units  forced  to  disaggregate.  In  addition,  blue  ModSAF  and 
BBS  artillery  was  fired  during  the  test.  As  confidence  in  the  system  increased,  minefields 
were  added  to  the  scenario.  Details  of  the  testing  the  entity  count  results  are  documented 
in  the  daily  test  logs. 
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When  the  Ml  and  M2  SIMNET  simulators  were  added,  Fort  Knox  operators  reported  that 
they  could  not  see  many  of  the  network  entities.  While  detailed  mapping  had  been 
performed  previously  first  using  NSC  assets  then  with  the  SIMNET  simulators  and  LRSs 
at  Fort  Knox,  only  minor  problems  had  been  identified  such  as  the  lack  of  an  OPFOR 
helicopter  in  the  Chodo  database  (reference  Appendix  C.  page  C-31.  The  fix  that  was 
pursued  was  to  use  the  Simdo  data  base  which  contained  an  appropriate  model  for  the 
OPFOR  helicopter.  A  ModSAF  scenario  containing  all  vehicle  types  was  provided  to 
Fort  Knox  for  testing  purposes  but  the  detailed  testing  of  each  model  type  and  ammo  typo 
was  not  performed  prior  to  loading  the  data  base  on  the  SIMNET  Image  Generators  (IG). 

Crashes  of  the  simulator  IGs  were  thought  to  be  related  to  improper  munitions  mapping. 
Munitions  mapping  was  checked  and  verified  or  corrected.  Results  of  the  munitions 
mapping  tests  can  be  found  in  the  Test  Log  presented  in  Appendix  G.  These  changes 
stabilized  the  IGs. 

Mapping  was  a  problem  all  the  way  through  to  the  start  of  the  exercise.  Problems  with 
munitions  mapping  were  still  being  identified  the  day  before  exercise  start.  Final  changes 
were  implemented  in  the  XCIAUs  rather  than  in  the  IG  mapping/DED  files. 

The  system  was  left  to  run  overnight  in  order  to  check  long  term  stability.  It  was  still 
running  after  16  hours,  with  one  Farm  back  end  lost  due  to  disk  error,  and  two  PVDs 
down  due  to  memory  leaks.  These  problems  were  determined  not  to  be  significant  in 
terms  of  the  exercise,  where  coordinated  archiving  and  shutdowns  were  scheduled  on  a 
daily  basis. 

The  LRS  vehicles  were  added  to  the  system  in  a  limited  capacity.  Introduction  of  three  of 
the  LRS  configurations,  the  ARPA  Reconfigurable  Simulator  Initiative  (ARSI),  the 
Reconfigurable  Combat  Vehicle  System  (RCVS)  113  and  the  RCVS  577,  produced  no 
additional  problems.  The  Dial-A-Tank  Reconfigurable  caused  system  crashes  in  both  the 
test  and  local  environments,  and  was  initially  dropped  from  the  exercise.  Eventually,  a 
method  of  configuring  Dial-A-Tank  using  the  XCIAU  to  filter  out  parts  of  the  system 
was  established  and  Dial-A-Tank  was  reintroduced  without  any  problems. 

Minefields  and  minefield-related  problems  continued  to  be  an  issue  through  FT2.  Since 
the  testing  of  other  functions  was  considered  to  be  complete,  the  main  focus  during  this 
phase  was  breaching  mines  with  ModSAF  or  disaggregated  BBS  vehicles.  The 
workaround  strategy,  detailed  in  the  Technical  Control  Document,  Appendix  H,  consisted 
of  limiting  red  minefields  to  BBS  generated  minefields,  and  having  Technical  Control 
magic  move  the  minefield  before  the  breach  is  made. 

On  28  August  the  system  was  given  to  the  customer  for  their  dry  run  of  the  exercise 
scenario.  Contractor  testing  and  last  minute  software  fixes  continued  from  29  August 
through  2  September. 
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5.5  Dry  Run  Summary  (Government  Responsibility) 

On  28  August  the  customer  dry  ran  the  STOWEX  96  scenario.  Involved  sites  included 
the  NSC,  the  BSC,  Fort  Riley,  Kansas,  the  MWSTC  and  the  MWTB,  Fort  Knox, 
Kentucky,  the  AVTB,  Fort  Rucker,  Alabama,  and  the  ASC  at  the  Pentagon.  The  NSC 
acted  as  host  and  Technical  Control.  The  BSC  at  Fort  Riley  operated  BBS  HICON.  The 
MWSTC  controlled  blue  ModSAF  forces.  Simulators,  including  SIMNETs  and  LRSs, 
from  Forts  Knox  and  Rucker  were  also  included  in  the  scenario  dry  run.  The  ASC  site 
functioned  as  a  viewport. 

The  customer  dry  run  enabled  all  parties  to  observe  system  performance  under  conditions 
that  more  closely  approximated  those  of  the  exercise.  Although  several  small  problems 
occurred  and  some  persisted  throughout  the  day,  the  dry  run  was  successful  in  that  all 
crashes  were  recoverable  and  the  entire  scenario  was  run.  The  contractor  log  for  this 
period  can  be  found  in  Appendix  G. 

5.5.1  Test  Suite  Configuration 

Facilities  diagrams  and  equipment  used  for  the  Customer  Dry  Run  are  the  same  as  those 
used  in  the  exercise.  They  are  given  in  Section  5.1 . 

5.5.2  Events  Summary 

At  0730,  conference  calls  were  initiated  from  the  NSC  to  all  involved  sites.  Startup 
procedures  were  followed  and  the  systems  were  initialized  and  brought  on  line.  At  0800 
the  AGs  at  all  sites  were  powered  up.  Fort  Riley  had  a  problem  powering  up  their  AG, 
resolved  by  removing  the  disk  drive  and  hitting  it  to  release  the  heads.  Fort  Riley’s  AG 
remained  off-line,  and  DSI  circuit  problems  were  identified  by  HAI.  DSI  problems 
persisted  throughout  the  morning  activities.  There  was  a  problem  initializing  BBS  and 
the  phone  line  connections  were  thought  to  be  responsible. 

BBS  was  connected  at  0958  and  the  test  scenario  was  started  at  1045.  There  were  several 
system  problems  at  the  outset,  including  simulator  lock-ups,  Farm  crashes,  and  IG  lock 
ups.  At  least  some  of  these  problems  were  thought  to  be  attributed  to  operator  error.  By 
1230  OPSIN  was  not  responding  to  game  resume  commands  and  a  lunch  break  was 
called. 

At  1300  all  DSI  lines  were  open  and  the  game  was  resumed.  Several  problems  were 
encountered  during  the  afternoon,  including  XCIAU  failure,  DSI  disconnects,  Stealth 
lock-up,  and  BBS  failure.  The  phone  lines  were  again  identified  as  the  source  for  BBS 
problems. 
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5.5.3  Dry  Run  Hot  Wash  Summary 

Main  topics  discussed  at  the  Dry  Run  Hot  Wash  include  the  following: 

1 .  Repeater  failure  caused  morning  BBS  log-in  problems. 

2.  Procedures  Checklist  (Technical  Control  Document)  was  updated  and  corrected. 

3.  Rebuilding  ModSAF  with  BBS  unpaused  failed,  but  there  is  no  problem 
rebuilding  ModSAF  with  BBS  paused. 

4.  Mapping  problems  were  thought  to  be  responsible  for  XCIAU  crashes  at  Knox 
and  Rucker  -  the  MCLIC  was  not  mapped  properly.  There  were  other  munitions 
that  were  also  improperly  mapped. 

5.  Image  Generator  crashes  were  also  attributed  to  mapping  problems:  Knox  noted  a 
crash  right  after  firing  a  Hellfire. 

6.  There  was  a  possible  bandwidth  problem  noted:  Rucker  saw  targets  pop  in  and 
out. 

There  was  a  problem  with  the  BBS  dial-up  lines:  they  would  drop  out  and  then  come 
back  on  line. 

The  system  was  returned  to  the  contractor  for  further  test  and  last  minute  software  fixes 
from  29  August  through  2  September. 

5.6  Exercise  Summary 

The  STOWEX  96  Training  Exercise  was  held  from  3  September  through  6  September 
1996.  Involved  sites  included  the  NSC,  the  BSC  at  Fort  Riley,  the  MWSTC  and  the 
MWTB  at  Fort  Knox,  KY,  the  AVTB  at  Fort  Rucker,  Alabama,  and  the  ASC  at  the 
Pentagon.  The  NSC  acted  as  host  and  Technical  Control.  The  BSC  at  Fort  Riley 
operated  BBS  HICON.  The  MWSTC  controlled  blue  ModSAF  forces.  Simulators, 
including  SIMNET,  AIRNET  and  LRSs  from  Fort  Knox  and  Fort  Rucker  were  also 
included  in  the  exercise.  The  ASC  site  functioned  as  a  viewport. 

5.6.1  Objectives 

The  main  objective  for  this  exercise  is  described  in  the  Exercise  Mission  of  the  1st 
Infantry  Division  (M)  Exercise  Directive  for  1st  Bde  Combat  Team  (1BCT)  BBS 
(STOWEX)  Command  Post  Exercise  DEVIL  WARRIOR  96-19.  3-6  September  1996. 
presented  as  Appendix  A  to  this  document: 

“...(to  conduct)  a  brigade  level  BBS  driven  Command  Post  Exercise  utilizing  the 
COBRAS  Training  package  3-6  September  1996  at  the  Fort  Riley  BSC,  Fort  Knox 
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BSC,  and  Fort  Rucker  (sic)  BSC  in  order  to  prepare  for  its  NTC  rotation  and  support  the 
STOWEX-A  test.” 

The  following  events  were  scheduled  for  the  exercise: 

03  Sept  Training  Day 

STARTEX  032400 
4  Sept  Area  Defense  Execution 

Change  of  Mission  1  (est  041200) 

AAR  #1  Change  of  Mission  +  5  hrs  (est  041700) 

05  Sept  Troop  Leading  Time 

06  Sept  LD  for  Deliberate  Attack  (est  060600) 

Change  of  mission  #2  (est  061000) 

AAR  #2  Change  of  Mission  +  5  hrs  (est  061500) 

1  -34  AR  index  est  NLT  06 1200 
1  -34  AR  Main  body  depart  for  Fort  Riley  at  061500 
07  Sept  1  -34  AR  arrives  at  Fort  Riley  (est  070300)  MISSION  COMPLETE 

5.6.2  Exercise  Equipment  Configuration 

Facilities  diagrams  and  equipment  used  for  the  STOWEX  96  Exercise  are  given  in 
Section  5.1. 

5.6.3  Events  Summary 

All  exercise  events  were  logged  at  both  NSC  and  Fort  Riley.  These  logs  are  presented  in 
Appendix  G.  From  a  technical  standpoint,  the  STOWEX  contribution  to  the  exercise  was 
a  success.  Until  the  final  day,  when  a  BBS  failure  caused  a  change  of  focus  in  the 
exercise,  the  schedule  was  followed  with  a  minimum  of  deviation.  From  an  operational 
standpoint,  however,  the  exercise  was  disappointing  in  that  STOWEX  did  not  participate 
in  the  Attack  mission. 

The  NSC  supported  the  exercise  by  functioning  as  Technical  Control.  The  Fort  Knox 
MWSTC  had  control  of  blue  ModSAF.  BBS  HICON  was  located  at  Fort  Riley.  With  the 
training  audience  at  Fort  Riley,  Fort  Riley  was  the  real  focus  during  the  exercise. 

The  following  sections  address  the  training  exercise  from  a  Fort  Riley  perspective. 

5.6.3.1  Performance  of  the  STOWEX  Hardware  and  Software  Suite 

With  the  exception  of  the  BBS  remote  communication  problems,  the  STOWEX  suite 
performed  as  expected.  The  STRIPES  3D  function  was  performed  by  an  SGI  ONYX 
borrowed  from  the  NSC  since  the  ICO  for  the  Maximum  Impact  was  not  available  from 
the  vendor.  The  PVD,  3D  and  Sound  Storm,  located  in  the  briefing  area,  generated 
interest  particularly  during  the  insertion  of  the  Fort  Rucker  RWA  simulators  into  the 
game.  The  STRIPES  PVD  and  Logger  was  used  minimally  during  the  first  AAR. 
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Although  demonstrations  and  training  were  provided  prior  to  the  exercise,  the  STRIPES 
3D  and  Unit  Performance  Assessment  System  (UPAS)  capabilities  were  not  utilized  due 
to  customer  preference.  The  AG  and  XCIAU  performed  normally. 

For  the  area  defense  portion  of  the  training  exercise  prior  to  the  change  in  mission,  the 
peak  local  entity  count  was  406  entities. 

Post  exercise  discussions  with  the  BSC  personnel  indicated  that  there  may  be  some 
additional  benefit  in  locating  a  PVD  in  the  HICON  /  EXCON  area  which,  during  the 
exercise,  contained  only  the  BBS  workstation  and  conference  telephones. 

S.6.3.2  BBS  Remote  Communication  Problems 

The  communication  link  between  the  BBS  workstations  at  Fort  Riley  and  the 
Micro VAXs  at  the  NSC  was  dropped  numerous  times  during  the  area  defensive  portion 
of  the  exercise.  A  dropping  the  link  resulted  at  a  minimum  of  an  automatic  re-dial  by  the 
modem  to  re-establish  the  link.  If  the  automatic  re-dial  was  not  successful,  BBS 
technician  intervention  was  required.  Frequently  this  intervention  involved  coordination 
between  the  NSC  and  Fort  Riley  technical  personnel,  removal  and  replacement  of 
modems  and  multiplexers,  and  /  or  resetting  of  the  BBS  workstation. 

These  repair  actions  generally  cleared  the  problem  at  least  temporarily  until  the  point 
when  all  efforts  failed  to  re-establish  any  remote  communications.  Communication 
linking  problems  continued  throughout  the  day  on  9/5  with  much  effort  expended  to 
resolve  the  problems  by  BSC  and  NSC  technical  personnel,  the  Fort  Riley  DOIM,  and  the 
local  phone  company.  In  order  to  support  the  training  exercise,  the  decision  to  revert  to 
local  BBS  was  made  at  0245  on  9/6. 

During  those  portions  of  the  game  when  STOWEX  was  being  used,  the  communication 
drop-outs  were  a  distraction  to  personnel  manning  the  BBS  cells  but  the  overall  impact  to 
the  game  was  minimal  due  to  reasonably  quick  repairs  and  the  ability  of  the  exercise 
control  team,  particularly  the  BBS  support  team,  to  make  the  problems  transparent  to  the 
trainees. 

It  should  also  be  noted  that  the  communication  linking  problems  had  been  previously 
seen  by  the  BSC  technical  personnel  prior  to  the  STOWEX  integration  &  test  and 
exercise.  BSC  personnel  also  indicated  that  previous  fixes  involved  action  by  the  NSC 
technical  staff. 

Post  exercise  troubleshooting  at  the  NSC  isolated  the  communication  problems  to  four 
coax  Ethernet  cables  between  the  BBS  VAXs.  These  cables  were  isolated  through  the 
use  of  a  simplified,  methodological  test  procedure  using  a  single  BBS  system.  Post 
exercise  discussions  have  indicated  that  the  problem  with  BBS  remotes  is  not  completely 
resolved. 
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5.6.3.3  Tactical  Communications 

More  realistic  tactical  communications  were  provided  in  STOWEX  96  than  in  previous 
STOW-A  exercises  which  utilized  simple  speaker  phones  and  human  facilitators. 
STOWEX  96  utilized  standard  military  FM  radios  (RT-524s)  in  the  Fort  Riley  TOCs  (1- 
16  and  1-34).  COTS  hardware,  RT-31  Tone  Remotes  and  TP-8  Tone  Termination 
Panels,  provided  the  capability  to  extend  the  four  real  time,  Push-to-Talk  (PTPT) 
communication  networks  from  the  Fort  Riley  TOCs  to  the  Division  Response  Cell  at  the 
BSC  and  to  Fort  Rucker  and  Fort  Knox  (2-34). 

Although  tactical  communications  proved  somewhat  difficult  to  establish  initially,  once 
established,  the  networks  worked.  Factors  contributing  to  the  difficulties  in  establishing 
communications  included  bad  radios  /  radio  mounts  and  unmodified  RT-31s  at  Fort 
Rucker. 

5.6.3.4  Exercise  Issues 

From  the  exercise  log  book  maintained  at  Fort  Riley  during  the  exercise,  the  following 
exercise  events  /  issues  need  to  be  evaluated  for  possible  correction  or  improvement: 

•  ModSAF  Crash  at  Fort  Knox  -  The  ModSAF  front-end  /  back-end  in  OC  station 
12  locked-up  about  0243  on  9/4.  Cause  is  still  to  be  determined;  however,  a 
ModSAF  memory  leak  problem  is  suspected. 

•  Insertion  of  SIMNET  Simulators  -  Preparation  for  inserting  the  vehicle  and 
aviation  simulators  began  0435  on  9/4  with  a  request  to  Fort  Knox  and  Fort 
Rucker  that  they  be  prepared  to  support  a  0530  mission.  Exercise  control  made  a 
decision  to  insert  the  aviation  simulators  as  scheduled  while  Fort  Knox  continued 
preparation.  Fort  Knox  simulators  were  unable  to  view  the  exercise.  The  MCC 
was  brought  down  and  it  was  determined  that  the  default  exercise  number  was 
being  used  rather  the  STOWEX  exercise  number  (exercise  number  7).  Fort  Knox 
simulators  were  inserted  into  the  game  at  0645. 

•  Multiple  Detonations  Viewed  in  STRIPES  3D  -  A  single  Hellfire  impacting  with 
the  ground  or  target  was  viewed  as  three  impacts  /  detonations  on  the  STRIPES 
3D. 

•  OPSIN  Crash  at  NSC  -  After  discussions  with  Fort  Rucker  regarding  their 
inability  to  view  155  HE  detonation  on  the  PVD,  NSC  identified  that  the  OPSIN 
was  down  (0125  on  9/5).  A  core  dump  was  saved  and  an  analysis  of  the  dump  is 
being  performed  by  Cambridge. 

5.6.4  Pentagon  Summary 

The  ASC  hosted  several  key  individuals  observing  the  STOWEX  96  Exercise.  In 
general,  the  briefings  given  by  LTC  Harry  Thompson  were  very  well  received  by  both 
DCSOPS  personnel  and  by  the  Office  of  the  Deputy  Undersecretary  of  the  Army  for 
Operations  Research  (DUSA-OR)  representative.  The  ability  to  observe  without 
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interference  and  with  a  minimum  of  preparation  was  considered  a  key  plus.  In  addition, 
distributed  simulation  capability  was  considered  to  have  advanced  considerably  since  the 
1994  STOW-E  demonstration.  Details  on  attendees  and  their  comments  are  given  below. 

The  ASC  hosted  personnel  on  both  Wednesday  and  Friday,  September  4th  and  6th. 
Focus  was  kept  on  the  manned  simulators  (both  the  Apaches  in  the  Deep  Attack  and  the 
Ml  and  M2  simulators). 

Attendees  at  the  Wednesday  sessions  included  both  Army  and  Air  Force  personnel.  Herb 
Fallin,  John  Rienti,  and  MG  Riggs  were  the  major  players  from  DCSOPS.  Also,  both 
Col  Ruth  and  Col  Hardin  of  AMSO  were  in  attendance.  Colonels  Ronnie  Stanfil  and 
Fred  Wall  represented  Air  Force  XOM. 

LTC  Thompson  emphasized  the  value  of  STOW-A  exercises  and  the  changes  that  had 
occurred  in  the  STOW-A  program  since  the  STOW-E  demonstration.  These  included  a 
more  sophisticated  and  stressful  training  environment,  a  larger  slice  of  the  brigade 
represented,  and  lower  costs  for  conducting  the  exercise  in  both  personnel  and  equipment. 
He  used  the  term  "Synthetic  CTC"  (Combat  Training  Center)  which  was  well  received. 

All  personnel  were  shown  both  the  Defense  in  sector  and  the  Apache  Deep  Attack.  MG 
Riggs,  former  commander  of  the  Army  Aviation  Center  and  highly  knowledgeable  on  the 
Fort  Rucker  simulation  environment)  was  very  concerned  about  the  loss  of  two  Apaches 
during  the  Deep  Attack  and  actually  called  for  a  count  of  the  number  of  vehicles  killed  in 
the  target  MRB  to  determine  the  loss  exchange  ratio.  He  was  not  only  interested  in  the 
tactics  used  and  the  SEAD  supporting  the  mission,  but  also  wanted  to  know  if  we  could 
listen  into  the  tactical  communications  from  the  exercise  (the  answer  was  no).  He  said  he 
would  be  very  interested  in  seeing  an  Executive  Summary  of  the  exercise  results  and 
especially  the  unit's  assessment  as  to  whether  this  helped  prepare  them  for  the  NTC.  MG 
Riggs  indicated  that  this  was  a  big  change  from  his  past  experience  with  large  scale 
exercises  and  demonstrations  in  that,  "Hopefully,  this  is  now  somewhat  simple  and 
transparent  [to  the  user].  I'd  rather  fight  a  real  enemy  than  prepare  for  some  of  the 
technology  demonstrations  we've  done."  However,  he  said,  ..."the  bottom  line  remains, 
what  did  they  [the  training  unit]  get  out  of  it?" 

On  Friday,  6  September,  Mr.  Vem  Bettancourt  of  DUSA-OR  attended  for  Walt  Hollis. 
The  Air  Force  XOM  was  again  in  attendance  as  Major  "Beef  Williams  sat  through  the 
briefing.  Mr.  Bettancourt  was  particularly  interested  in  the  future  of  STOW-A  and  was 
pleased  to  see  the  scheduled  transition  from  BBS  to  WARSIM  as  the  constructive  model. 
He  was  also  interested  in  a  follow-up  with  the  unit  in  the  March  timeframe  (after  the  NTC 
rotation)  to  see  if  the  unit  found  value  in  the  STOW-A  exercise.  Mr.  Bettancourt  also 
indicated  that  it  was  good  to  see  the  Guard  and  Active  forces  interacting  as  there  were 
few  opportunities  for  that  to  occur. 

Mr.  Bill  Bewley  of  AB  Technologies,  a  support  contractor  for  the  Defense  Modeling  and 
Simulation  Office  (DMSO),  was  also  in  the  briefing.  Mr.  Bewley  was  a  key  individual  in 
the  STOW-E  demonstration  and  his  organization  also  played  a  major  role  in  the 
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STOW/PW  95  demonstrations.  He  was  very  complimentary  of  the  changes  that  had 
occurred  in  the  system,  but  warned  that  the  real  test  was  whether  the  Brigade  would 
program  future  STOW-A  exercises.  He  said  Capt  Hollenbach  of  DMSO  was  appreciative 
of  "real  stuff."  He  suggested  that  the  debriefing  of  the  Brigade  include  the  same 
questions  asked  of  Col  Dean  Cash  in  STOW-Europe  demonstration  to  get  a  comparison 
of  the  results. 

Cpt  Irview  attended  for  the  Army  Intelligence  Staff.  He  is  a  DCSINT  staff  officer  for 
distributed  simulation  and  has  been  involved  with  the  Virtual  Unmanned  Air  Vehicle 
(UAV)  already  in  use  at  the  NTC.  He  said  that  he  would  check  out  the  status  of  the  UAV 
system  and  report  back  to  AMSO  concerning  the  possibility  of  integrating  it  with  STOW- 
A. 


5.6.5  Post  Exercise  STOWEX  Suite  Configuration 

The  STRIPES  PVD,  Sound  Storm,  and  the  three  37”  monitors  (for  3D  display)  were 
reinstalled  in  the  STOW-A  work  cell  where  the  XCIAU,  Logger  and  Maximum  Impact 
were  located  for  the  exercise.  Network  checks  were  performed  for  the  reinstalled 
systems.  Installation  of  the  Maximum  Impact  ICO  will  be  performed  at  a  future  date 
after  receipt  of  the  hardware  from  the  vendor.  The  borrowed  ONYX  was  returned  to  the 
NSC.  The  RT-3  Is  and  TP-8s  were  to  be  shipped  to  the  NSC  at  a  later  date. 

5.6.  6  Technical  Hotwash  Summary 

This  section  represents  the  STRICOM  notes  of  the  Technical  Hotwash  teleconference. 

A  STOWEX  96  Technical  Hotwash  was  conducted  on  9  September  1996  at  1500  EDT, 
with  the  NSC  as  the  moderator.  Participating  sites/organizations  are  listed  below: 

Fort  Leavenworth-NSC 

Fort  Leavenworth-BCTP  OPS  GP  B 

Fort  Riley  -  G-3  &  BSC 

Fort  Knox  -  MWSTC 

Fort  Knox  -  FXXITP 

Fort  Rucker  -  AVTB 

1/211  Atk  Hel  Bn,  Utah  ARNG 

STRICOM/Lockheed-Martin 

Army  Simulations  Center 

Each  site/organization  was  requested  to  present  three  “Ups”  (positive  points)  and  three 
“Downs”  (points  that  need  improvement)  for  the  exercise.  The  only  site  to  rank  order 
input  was  the  NSC. 
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Fort  Knox 

+  Validation  of  synchronization  of  STOWEX  and  autonomous  operations  (i.e., 
ability  to  switch  between  STOWEX  and  VTP) 

+  Brigade  Commander  and  Staff  (with  logistics  tail)  made  the  exercise  more 
realistic  for  TF  1-34  AR  (than  using  role  players) 

+  The  backup  plan  and  the  capability  to  execute  training  outside  of  STOW-A 
environment 

+  LRS  performance  (from  FXXITP) 

-  Standardization  of  HW  and  SW  -  not  knowing  up  front  what  the  technical 
architecture  was 

SW  -  DED  and  Mapping  files.  Must  be  standardized  up  front. 

-  SW  -  Aggregation/disaggregation  -  ranges  at  which  disaggregation  occurred 
The  terrain  database  did  not  match  up  between  Constructive  and  Virtual 
(BBS  disaggregated  vehicle  traversing  NOGO  terrain. 

Requirements  need  to  be  defined  prior  to  exercise 

Fort  Rucker 

+  Training  benefit  to  1/211.  Could  have  been  used  more  in  the  scenario. 

+/-  Confusion  over  ModSAF  RWA  ROE.  Used  existing  (in-house)  ROE  to 
overcome  confusion 

DARPA  map  detail  does  not  always  come  together.  AVTB  used  ModSAF 
TDB  different  from  other  sites. 

-  AVTB  needs  equivalent  to  SIMNET  MCC  to  place  AIRNET  entities  on 
battlefield. 

Communications  coordination  (TAC  COMMS)  -  resister  required 
modification  in  RT-31.  Once  modified  and  established,  comms  were  pretty 
stable. 

Entity  enumeration  and  DED  standardization 

1/21 1  Attack  Helicopter  Battalion,  UTAH  ARNG 

+  One  of  the  best  training  opportunities  for  him  and  his  unit 
+  Real-time  feedback  from  mission;  no  need  to  pretend  or  makeup. 

+  Seemed  to  simulate  "fog-of-war"  well. 

+  Gave  feel  for  working  with  other  units  (e.g..  SEAD  coordination) 

-  Difficulty  in  playing  on  same  "gameboard"  (disaggregation  was  controlled 
because  of  massive  disaggregation  potential) 

-  VTC  shortfalls  (lack  of  multi-point  VTC) 

Limited  size  of  playbox 

Confusion  over  the  different  types  of  targets  (this  relates  to  mapping  and 
visualization) 
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Fort  Leavenworth  -  BCTP  Operations  Group  B 

+  Training  took  priority  over  testing 
+  Quick  support  to  fix  technical  problems 

+  Exposed  many  to  the  STOW-A  "possibilities"  -  Subordinate  units  got  more 
from  it  than  did  Bde 

-  Technical  difficulties  precluded  recon  on  Thursday 

-  BBS  AAR  new  to  the  team.  Did  not  use  STRIPES  to  fullest  capability.  When 
DIS  environment  went  down  at  Riley  on  6  September,  so  did  STRIPES. 

Good  database  scrub  with  playing  unit  is  necessary,  e.g.  reinforcing  artillery 
and  MLRS  different  than  unit  plan.  Also,  numbers  of  personnel  and  MOSs  in 
units  different  than  unit  plan. 

Fort  Riley 

+  Did  not  see  significant  change  in  personnel  overhead  (in  BSC)  by  being  in 
STOW-A  environment. 

+  OC  team  provided  by  BCTP 

+  Contingency  plans  anticipated,  executed  and  they  worked. 

+  TF  1-34  AR,  in  a  STOW-A  environment,  receiving  C2  from  1BCT 

-  Lack  of  visual  architecture  at  each  site  (may  have  helped  to  diagnose/isolate 
problems  on  Thursday) 

-  Wednesday  -  unexplained  loss  of  archived  data  on  BBS  AAR  system.  Data 
not  avail  for  AAR.  C-V  environment  not  entirely  seamless.  Artificial  rules 
for  control  of  disaggregation  (e.g.  RWA) 

Quality  of  phone  lines  used  for  BBS  remote 

-  750  icon  limit  for  BBS.  Was  nearly  reached.  Were  close  to  that  point  when 
game  went  down 

Maneuver  box  limitation  -  was  compressed  to  keep  everything  together. 
Tactical  comms  went  down  at  inopportune  times 

ModSAF  Memory  Leak  and  refresh  of  system  -  inability  of  brigade  to 
maintain  rhythm 

-  Dissemination  of  graphics  to  remote  locations 
STRICOM/Lockheed  Martin 

+  Coordination  of  Technical  Control  went  very  well;  reduced  number  of 
personnel  to  run  the  exercise 

+  Achieved  goal  of  500+  local  vehicles  on  Farm  during  Functional  Test  II; 

Reached  406  local  vehicles  during  exercise  and  could  have  gone  higher 
+  Validated  implementation  of  structured  startup/recovery  and  shutdown 
procedures. 

-  Unexplained  OPSIN  crashes  (3) 

-  Mapping  file  and  DED  File  -  last  minute  changes 

-  ModSAF  Memory  leak  required  periodic  refresh  of  system 
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Army  Simulation  Center 

+  Leadership  was  very  happy  with  exercise  and  the  improvements  that  have 
been  made  over  the  past  year 

+  CSA  wants  to  make  a  tape  of  the  exercise  for  all  to  see. 

Fort  Leavenworth  -  NSC  (in  Rank  Order): 

+  Hub  concept  can  support  brigade  level  exercises 
+  Found  a  significant  reduction  in  personnel  overhead 
+  Defense  Simulations  Internet  (DSI) 

-  ModSAF  Memory  Leak 

-  BBS  network  problems 

-  Data  (DED)  mapping 

5.7  Equipment  Disposition 

Appendix  I  contains  the  final  disposition  of  STOW-A  equipment.  This  disposition 
provides  both  the  NSC  and  the  BSC  with  the  infrastructure  to  conduct  future  exercises 
similar  in  size  to  STOWEX  96. 

5.8  STOWEX  1.5  Baseline  Management 

5.8.1  Baseline  Control 

Baseline  control  is  the  process  of  ensuring  authorized  changes  are  incorporated  in  a  given 
software  system  and  are  placed  in  a  protected  area  to  preserve  the  system  integrity.  For 
STOWEX  96,  baseline  control  of  OPSIN/ModSAF  was  the  responsibility  of  the  Software 
Engineers  in  Cambridge,  MA.  The  management  tool  used  is  the  Change  Version  System 
(CVS).  The  tool  tracks  changes  and  supports  the  development  and  maintenance  of 
multiple  versions  of  software  units.  All  other  STOW-A  software  was  controlled  in  the 
Orlando  ADST  II  facility.  The  Configuration  Management  issue,  documented  below  in 
Section  6,  describes  the  baseline  control  process  that  has  been  tailored  to  respond  to 
STOWEX  96  issues  and  timelines. 

5.8.2  Change  Management 

The  purpose  of  change  management  is  to  ensure  all  changes  are  identified,  implemented 
and  documented.  The  first  step  in  change  management  is  to  identify  the  Initial  Baseline. 
The  Initial  Baseline  for  OPSIN/ModSAF  was  established  as  version  1.92,  June  28,  1996. 
Refer  to  Section  2  for  a  list  of  Version  Description  Documents  (VDD)  for  specific  Initial 
Baseline  Definitions. 

As  problems/deficiencies  were  identified,  Software  Review  Boards  were  held  to  review 
the  problem/deficiency.  The  review  was  chaired  by  the  STOWEX  Project  Engineer.  The 
Technical  Team  analyzed  the  implementation  approach  and  risk  factor  and  recommended 
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Action  or  No  Action.  The  No  Action  was  dependent  upon  the  risk  factor  and  impact  to 
the  overall  system.  Once  an  Action  recommendation  was  issued,  the  problem/deficiency 
was  written  as  a  requirement,  implemented  and  tested  by  the  Software  Engineer  and 
integrated  into  the  system.  The  changes  are  captured  in  the  specific  VDDs. 

5.8.3  Summary  of  STOWEX  96  Discrepancy  Reports 

Two  significant  software  issues  emerged  from  the  final  integration  efforts  and  the 
exercise.  The  first  problem,  described  as  an  “OPSIN  Hang”,  was  documented  and 
patched  on-site  after  a  Software  Review  Board  decision.  The  following  describes  the 
problem  and  the  temporary  correction: 

Problem:  OPSIN  “hangs”  for  no  apparent  reason. 

Symptoms:  Parser  does  not  respond,  OPSIN  is  not  printing  “Missed  xx 
packets...” 

Diagnosis:  OPSIN  gets  into  a  not  quite  infinite  loop  in  the  last  k  indexed  'for’ 
loop  in  cs_set_supplies().  This  function  calculates  how  much  of  a  given  supply 
the  unit  needs  and  distributes  it  across  the  appropriate  vehicles  in  the  unit.  The 
distribution  is  done  in  a  loop  that  will  only  exit  when  the  remaining  supplies 
equals  zero.  Unfortunately  in  certain  yet  undermined  circumstances  the 
remaining  supplies  starts  negative  which  the  exit  criteria  are  not  designed  to  work 
with,  it  also  screws  up  the  ammo  distribution. 

Patch:  Change  the  exit  criteria  for  the  loop  to  exit  if  remaining  supplies  is  ever 
less  than  or  equal  to  zero.  Also  add  a  printf  to  print  the  message  “Negative 
remaining  supplies  for  unit  <unit  name>.”  If  the  remaining  supplies  ever  starts 
negative,  this  allows  us  to  confirm  if  the  problem  reoccurs  and  that  the  patch  has 
fixed  it.  Also  is  an  indication  that  the  unit  in  question’s  supplies  may  not  be  in 
sync  with  BBS  and  if  the  unit  is  disaggregated,  steps  should  be  taken  to  re-sync 
the  unit’s  supplies  across  BBS  and  ModSAF. 

The  second  problem  is  called  the  “ModSAF  Memory  Leak”  and  is  characterized  by  a 
crash  after  the  ModSAF  had  been  running  for  a  period  of  time.  After  the  exercise  was 
run,  an  analysis  tool  called  “Purify”  was  run  at  the  OSF  with  ModSAF  2.1  on  both  an 
SGI  Indigo2  (IRIX  5.3)  as  a  pocket,  and  on  an  R10000  (IRIX  6.2)  as  a  Farm  and  PVD. 
The  Farm  consisted  of  2  machines.  The  ModSAF  scenario  consisted  of  4  platoons;  2  on 
the  Farm,  2  on  the  pocket,  and  1  fixed  wing  group  on  each.  These  entities  remained 
stationary  during  the  run.  Of  the  3  R1 0000s,  2  developed  hardware  problems  and  crashed 
during  the  weekend  run.  Purify  reported  the  following  errors: 

1.  Memory  Leaks  (42):  Data  is  not  freed  when  it  is  no  longer  needed  and 
accumulates  until  all  available  memory  has  been  consumed,  resulting  in  a  crash. 
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2.  Array  Bound  Write/Read  (8/16):  Data  is  being  written  to/read  from  an  area  that 
has  not  been  allocated  by  the  software  during  the  execution.  Array  Bound  Write  is 
an  example  of  memory  corruption  and  could  cause  the  application  to  crash.  With 
Array  Bounds  Read  the  data  read  may  be  random,  and  can  cause  random  behavior 
or  a  crash.  The  8  statements  causing  an  Array  Bounds  Write  error  were 
called/executed  28,076,261  times.  The  16  statements  causing  an  Array  Bounds 
Read  were  called  980  times. 

3.  Free  Memory  Read  (4):  Data  is  being  read  from  a  location  that  is  no  longer  valid. 
The  software  has  ‘released’  that  section  of  memory  and  the  data  read  may  be 
random,  and  can  cause  random  behavior  or  a  crash.  The  4  statements  performing 
a  Free  Memory  Read  were  called  108  times. 

4.  Uninitialized  Memory  Read  (55):  Data  is  being  read  from  a  location  that  was 
never  initialized.  If  the  data  was  not  initialized  before  it  is  used  it  can  introduce  a 
more  severe  error,  such  as  those  stated  above.  The  55  statements  causing  the 
Uninitialized  Memory  Read  were  called  a  total  of  4,002,018  times. 

Additional  testing  is  recommended  for  this  problem,  to  include  rigorous  testing  of 
ModSAF  under  a  system  load  of  at  least  150  local  entities  on  each  of  the  ModSAF 
workstations  for  at  least  2  hours. 

In  addition  to  the  software  problems,  the  following  problems  were  also  identified  during 
the  exercise  support  activities: 

•  The  version  of  ModSAF  compiled  for  6.2  was  not  reliable.  Since  IRIX  6.2  was  a 
newly  delivered  operating  system,  there  was  not  sufficient  time  to  compile  and 
test  in  the  OSF  prior  to  shipment.  Attempts  to  compile  on  site  were  unsuccessful. 
Since  the  reliable  5.3  version  executed  on  the  6.2  machines,  the  compilation  effort 
was  deferred  until  post-exercise.  The  effort  is  being  tracked  until  completion, 
including  verification. 

•  Mines.  There  seemed  to  be  no  effective  method  for  blue  vehicles  to  breach  red 
minefields.  A  Grizzly  following  a  MCLIC  was  frequently  destroyed  by  mines 
trying  to  make  the  breach.  Also,  breaching  minefields  caused  the  Ml  and  M2 
simulators  to  crash.  Changing  the  mine  type  in  the  red  minefields  had  no 
beneficial  effects.  The  development  of  workarounds  during  site  testing  is  a 
difficult  task  unless  personnel  who  are  familiar  (experienced  users  and/or 
developers)  are  present.  For  example,  the  use  of  the  Grizzly  vehicle  or  MICLK  to 
clear  the  minefield  did  not  provide  the  expected  results  since  the  Grizzly  proved 
extremely  vulnerable  to  the  mines.  Alternative  methods,  such  as  deleting  or 
removing  the  minefield,  often  caused  the  ModSAF  Farm  to  crash.  Further 
investigation  is  required  to  identify  the  requirements  against  which  the  minefield 
and  breaching  functions  were  built  to  determine  whether  they  performed  in 
accordance  with  Engineering  School  doctrine.  Results  must  then  be  discussed 
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with  the  STOW- A  user  community  to  (a)  agree  upon  an  acceptable  behavior 
during  an  exercise  or  (b)  develop  one  or  more  workarounds  in  an  environment 
where  the  outcome  can  be  predicted  and  tested.  This  issue  relates  to  both  the 
Requirements  issue  and  the  Planning  Time  issue  documented  below  in  Section  6. 

Post-exercise  activities  include  the  evaluation  of  the  test  log  to  identify  issues,  such  as  the 
dead  hulk  problem,  that  will  be  written,  dispositioned,  and  tracked. 

5.9  Risk  Mitigation 

The  SGI  Impact  Channel  Option  (ICO)  that  enables  the  Maximum  Impact  to  drive  more 
than  one  monitor  was  a  production  problem  for  SGI.  Two  risk  mitigation  plans  were 
devised.  The  first  was  to  procure  a  cable  that  connected  the  13W3  Impact  to  a  single 
RGB  37”  monitor.  The  second  plan  included  borrowing  a  loaner  Onyx  from  different 
sources.  The  first  method  was  employed. 

The  newly  announced  R 10000  processors  procured  for  OPSIN  and  the  ModSAF  Farm 
also  presented  a  risk.  The  R10000  were  prone  to  failure  and  have  been  recalled  and  in  the 
process  of  being  replaced.  Therefore,  several  spare  machines  were  sent  to  the  NSC  for 
back-up. 
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6.0  STOWEX  96  Issues  and  Recommendations 

There  were  7  major  issues  identified  during  STOWEX  96.  These  are: 

1 .  Improved  control  of  the  DSI 

2.  Earlier  completion  of  vehicle  mapping  across  simulation  platforms 

3.  Earlier  availability  of  exercise  control  information 

4.  Definition  of  requirements  and  design 

5.  Configuration  management 

6.  Planning  time 

7.  Technology  advancement 

6.1  DSI  Issue  and  Recommendation 

Issue:  Connectivity  testing  was  performed  prior  to  the  actual  exercise  testing.  The 
connectivity  test  showed  that  all  IP  and  stream  connections  were  up  and  available  for  use. 
Defense  Simulation  Internet  (DSI)  problems  began  when  actual  simulation  traffic  was 
generated  and  transmitted  over  the  network.  Although  specific  testing  of  the  long  haul 
data  communications  was  performed  well  in.  advance  of  the  exercise,  problems  were 

encountered ---during . -the . week . prior  to . the  exercise  when  all  'long  haul  sites  were 

integrated.  The  most  obvious  symptom  was  the  inability  of  Fort  Rucker  to  receive  the 
proper  entity  count  at  the  AG.  The  troubleshooting  that  ensued  included  extensive 
conversations  with  HAI.  The  following  problems  were  experienced. 

1.  HAI's  new  "Dual  Hemmgr— software— imposed- . -a— bandwidth . . penalty  due  to 

additional  software  overhead. — Since  blnitial  bandwidth  allocations  for  each  site 
had  been  allocated  set  based  on  PW95  experience.-  When  the  entity  count 
problem  occured.  fhe^edueed-bandvwdthravailabilkv-fesulteddn-entitv-  drop  out  at 
Fort  Rucker.  bSandwidth  allocations  were  reduced  for  ASC  and  Fort  Riley  since 
these  sites  would  not  be  generating  network  traffic  (final  allocations  documented 
on  page  G- 1  ()  1 ).  During  periods  when  STOW  functional  testing  was  not  being 

performed,  HAI  worked  to  improved  the  bandwidth  (reduced . the . software 

overhead),  problem.  Subsequent  information  from  HAI  indicates  that  there  was  a 
"bad"  Tl  link  (suspect  that  a  service  provider  had  misconfigured  or  attached 
some  additional  component  to  the  link). 

2.  Router  configuration  problems  at  Scott  resulted  in  an  excessive  number  of  sites 
being  assigned  to  a  single  processor.  This  configuration  problem  was  resolved. 

3.  HAI  could  not  provide  routing  through  Scott  which  was  required  for  Fort  Rucker's 
"Dual  Homing"  channel.  While  the  lack  of  the  second  /  redundant  channel 
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prevented  conducting  the  exercise  simultaneously  with  VTC,  the  exercise  itself 
was  not  impacted.  This  routing  problem  was  never  resolved  by  HAI. 

4.  During  functional  testing,  coordination  /  communication  problems  between  HAI 
personnel  on  different  work  shifts  would  result  in  the  HAI  night  shift  changing 
network  configurations  that  functioned  during  the  day.  Not  only  were  the 
changed  configurations  were  unusable  by  the  STOW  team  at  the  beginning  of  the 
day,  the  day  shifts  were  unaware  that  the  changes  had  been  made. 

Recommendation:  The  test  plans  properly  identified  the  need  to  perform  the  connectivity 
test  very  early  in  the  test  schedule.  Unfortunately  for  STOWEX  96,  resolution  of  the 
problems  with  HAI  consumed  far  more  time  than  planned.  Recommendation  is  to 
continue  planning  for  early  DSI  testing  with  network  loads  simulating  expected  exercise 
conditions. — Although,  an  HAI  representative  was  eventually  included  in  the  daily 

technical  calls,  ine4^sien-Trom--the-start . ef-testing  would  have  been 

beneficial;  In  order  to  avoid  numerous  personnel  at  HAI  providing  inconsistent  support, 
a  subcontract  with  HAI  for  one  exercise  support  engineer  is  warranted.  The  exercise 
support  engineer  should  be  required  to  remain  on  a  teleconference  during  the  functional 
tests  and  exercise.  If  additional  equipment  is  required  to  provide  dual  homing 
capabilities,  installation  should  be  performed  sufficiently  early  to  allow  for  testing  of  the 
exercise  network  with  actual  exercise  traffic. 

6.2  Mapping  Issue  and  Recommendation 

Issue:  Final  mapping  was  performed  late  in  the  integration  and  test  phase  and  affected  the 
test  events.  For  STOWEX  96,  vehicle  types,  weapon  systems  and  munitions  types  were 
identified  or  could  be  derived  from  the  Exercise  Directive  and  TOE  prior  to  the  exercise. 
Based  on  the  difficulties  with  mapping,  this  information  is  needed  as  early  in  the  program 
as  possible  to  support  testing.  In  addition,  information  that  supports  the  development  of 
test  scenarios  that  will  stress  the  system  in  the  same  manner  as  the  one(s)  to  be  used  in 
the  actual  exercise  are  required  to  support  test  program  (terrain  data  base  testing,  mapping 
verification,  load  testing,  STRIPES  initialization,  etc.).  Information  that  will  be  needed 
includes: 

•  List  of  vehicle  types, 

•  Unit  designations, 

•  Initial  task  organization, 

•  Real  world  map  of  the  play  box, 

•  Operation  overlays  or  at  a  minimum,  a  listing  of  control  measures  with  grid 
coordinates, 

•  Definition  of  mission  with  connections  to  control  measures, 

•  Simulator  IDs  by  TOE  position  and  initial  locations  in  the  gaming  area. 
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Resolution:  The  identification  of  all  vehicles  and  ammunition  to  be  used  in  the  actual 
Exercise  must  be  agreed  upon  and  made  available  to  the  Contractor  during  the  design  and 
development  phase  in  order  to  establish  mapping  tables.  The  scenario  to  be  used  during 
the  Dry  Run  and  the  Exercise  must  be  provided  to  the  Contractor  prior  to  OSF  testing  in 
order  to  test  the  mapping  and  resolve  mapping  issues  in  a  timely  manner.  This  resolution 
also  falls  under  the  recommendation  of  an  Exercise  Control  Plan,  Issue  6.3. 

6.3  Exercise  Control  Information  Issue  and  Recommendation 

Issue:  The  STOWEX  96  Delivery  Order  originally  contained  a  requirement  for  the 
Contractor  to  deliver  an  Exercise  Control  Plan.  This  requirement  was  reallocated  from 
the  Contractor  to  the  Government.  The  plan  was  not  received  in  time  to  support  many  of 
the  technical  activities.  As  a  result,  none  of  the  testing  was  performed  against  the 
exercise  scenario.  Vehicle  and  ammunition  mapping  was  accomplished  on  site  rather 
than  during  the  design  and  development  phase  and  tested  against  Contractor  developed 
scenarios.  The  final  mapping  issues  were  not  identified  until  after  the  true  exercise 
scenario  was  provided  at  Dry  Run.  The  decision  to  have  a  ModSAF  red  air  attack 
contingency  at  the  NSC  was  made  during  final  integration  and  not  clearly  communicated 
to  all  parties. 

Other  issues  that  would  typically  be  defined  in  an  Exercise  Control  Plan  include  the 
identification  and  allocation  of  roles  and  responsibilities.  While  most  roles  and 
responsibilities  were  explicitly  or  implicitly  understood,  some  (such  as  responsibility  for 
training  site  personnel  on  usage  and  maintenance  of  STOW-A  equipment)  were  not 
identified  until  the  Exercise  Dry  Run.  The  need  and  responsibility  for  developing  a  test 
scenario  for  Blue  ModSAF  would  have  been  identified  early.  An  agreed-to  list  of 
stations  to  be  staffed  and  the  resulting  responsibilities  would  identify  scope  issues  and 
establish  assignments  in  advance.  Responsibilities  and  procedures  for  voice 
communication  networks  would  be  established  earlier.  The  availability  of  all  sites  to 
support  multiple  shift  activity  must  be  identified  in  advance. 

Recommendation:  The  Contractor  should  develop,  as  a  minimum,  an  exercise  control 
checklist  in  order  to  ensure  that  critical  items  are  being  addressed  in  sufficient  time  to 
reduce  program  risks.  Appendix  J  provides  a  recommended  outline  and  a  generic 
planning  timetable  that  starts  6  months  prior  to  the  exercise.  Even  if  this  is  not  a 
deliverable  document,  it  identifies  the  planning  activities  that  the  Contractor  must 
undertake  and  the  inputs  that  must  be  solicited  from  the  Government.  This  outline  is 
based  upon  previous  plans  that  have  guided  successful  exercise  results. 

6.4  Definition  of  Requirements  and  Design  Issue  and  Recommendation 

Issue:  In  order  to  provide  a  baselined  STOW-A  infrastructure,  a  comprehensive 
requirements  and  design  effort  must  be  performed  and  documented.  This  task  includes 
the  definition  of  operational  concepts  performed  in  concert  with  the  Government  either 
from  SOWs,  technical  interchanges,  or  derived  from  the  Contractor’s  understanding  of 
Government  objectives.  Comprehensive  requirement  statements  must  be  developed  to 
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include  not  only  the  descriptions  of  existing  “as-built”  functionality  but  also  the 
perceived  and,  ultimately,  the  agreed-upon  objectives  against  which  the  system  must  be 
developed,  rather  than  the  verbal  goals  that  may  be  verbalized  over  time  but  not  specified. 

Recommendation:  Appendix  K  presents  an  initial  set  of  system  and  subsystem 
requirements  for  STOWEX  96.  These  requirements  are  not  complete  and  currently 
reflect  an  as-built  set  of  capabilities  rather  than  the  statements  of  known  customer 
specifications  and  constraints  that  are  either  provided  or  derived  through  analysis  from 
experience,  technical  interchanges,  and  related  documentation.  A  thorough  requirement 
analysis  effort  should  be  performed  in  order  to  provide  a  complete  set  of  STOWEX 
specifications  in  the  future.  Once  requirements  have  been  developed  and  approved,  the 
allocation  of  those  requirements  to  a  STOW-A  design  can  be  performed  and  documented 
in  a  manner  similar  to  Section  4  of  this  document,  leaving  the  program  with  a  clear 
definition  of  the  hardware  and  software  required  for  the  infrastructure.  Once  this  baseline 
is  established,  exercise  specific  items  can  be  addressed  and  site-specific  architectures 
easily  developed. 

In  addition  to  functional  and  performance  requirements,  other  requirements  such  as 
Training,  Shipping,  and  other  procedural  requirements  that  are  not  accomplished  by 
hardware  or  software  must  be  developed.  In  the  future,  for  example,  shipping 
requirements  must  be  identified  well  in  advance  particularly  when  the  equipment  is  to  be 
permanently  transferred  to  the  receiving  sites.  In  addition,  if  overseas  delivery  is 
required,  additional  logistical  constraints  must  be  identified  and  planned  for  (i.e., 
transoceanic  vs.  air  shipment,  customs  issues,  etc.).  Training  requirements  for  all  new 
STOW-A  equipment  added  to  each  STOW-A  site  must  also  be  identified.  For  example, 
Fort  Riley  technicians  need  to  be  trained  on  the  operation  and  maintenance  of  SGI 
equipment.  Providing  start-up  and  shut-down  procedures  is  necessary,  but  operational 
familiarity  is  mandatory.  During  the  Government  conducted  Dry  Run,  the  Riley  AG 
would  not  boot  until  the  hard  drive  had  been  removed  and  manipulated  until  the  heads 
released.  This  was  identified  via  teleconference  with  Technical  Control  at  the  NSC,  but 
should  have  been  performed  by  the  BSC  site  contractor. 

6.5  Configuration  Management  Issue  and  Recommendation 

Issue:  The  purpose  of  change  management  is  to  ensure  all  changes  to  hardware  and 
software  are  identified,  implemented  and  documented.  The  following  four  issues  were 
identified  during  STOWEX  96. 

The  first  issue  pertains  to  software  developed  and  maintained  by  subcontractors.  Even 
though  ADST  II  has  in  place  a  Configuration  Management  Plan,  some  subcontractors 
may  not.  Subcontractors  maintain  and  develop  their  software  and  do  not  necessarily  in  a 
implement  an  adequate  configuration  management  process.  The  STOWEX  96  team 
brought  the  source  code  and  data  files  under  the  ADST  II  Configuration  Management 
process  and  the  team  requested  on-site  support  for  the  software  from  the  subcontractor. 
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This  enabled  the  STOWEX  96  team  to  control  and  track  the  changes  being  incorporated 
into  the  baseline. 

The  second  issue  pertains  to  off-site  configuration  management  process.  It  is  a  challenge 
to  maintain  configuration  management  process  at  multiple  sites  and  with  multiple 
versions.  However,  the  STOWEX  96  team  maintained  logs  of  observations,  happenings 
and  changes.  These  logs  were  used  in  creating  the  Version  Description  Documents. 

The  third  issue  pertains  to  changing  the  software  or  data  files  prior  to  the  exercise  and 
then  sending  the  same  updated  software  or  data  files  to  the  other  sites.  Changes  are 
inevitable.  As  changes  were  incorporated,  the  STOWEX  96  team  quickly  recognized  that 
the  software  at  all  the  sites  must  be  the  same  for  successful  training.  The  team  copied  the 
updated  software  onto  tapes  and  mailed  the  tapes  with  an  overnight  delivery  to  the 
appropriate  sites.  It  was  helpful  to  engineering  support  in  Orlando  to  support  the 
software  efforts. 

The  last  issue  pertains  to  hardware  configuration.  The  hardware  at  the  simulation  sites 
were  installed  prior  to  a  training  exercise.  As  additional  hardware  arrived,  the 
configuration  of  the  system  was  modified  prior  to  the  exercise  by  the  addition  of  memory 
and  internal  harddrives.  The  STOWEX  96  team  was  quick  to  respond  to  re-configure  the 
hardware  system  as  the  additional  equipment  arrived.  The  documentation  of  the 
hardware  configuration,  although  known,  was  not  fully  captured  until  final  reporting 
effort. 

Recommendation:  Recommendations  include  improving  the  STOW-A  Configuration 
Management  Process  by: 

1.  Placing  the  subcontractors’  source  code  into  the  ADST  II  Configuration 
Management  control, 

2.  Placing  all  source  code,  excluding  the  BBS  software,  into  the  ADST  II 
Configuration  Management  control  and  during  development,  placing  the  main 
components  into  the  STOW-A  configuration  control  at  OSF,  since  most 
changes/development  will  be  at  the  OSF, 

3.  Having  an  on-site  configuration  control  engineer  during  the  pre-exercise  phase 
to  capture  changes,  control  software  and  update  other  sites  as  applicable, 

4.  Having  the  on-site  configuration  control  engineer  to  capture  initial  hardware 
baseline  at  the  site  and  at  the  end  of  the  pre-exercise/exercise. 

6.6  Planning  Time  Issue  and  Recommendation 

Issue:  The  time  between  contract  start  and  the  beginning  of  a  STOW-A  exercise  is  never 
sufficient  to  perform  the  detailed  planning  required  to  design  and  develop/procure  and 
test  the  STOW-A  systems. 
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Recommendation:  The  development  of  a  reusable  Exercise  Control  Plan  and  a 
Requirements  and  Design  Document  for  STOW-A  will  baseline  the  activities  required  by 
all  exercise  developers  and  participants  as  well  as  the  “typical”  STOW-A  “product.” 
Streamlining  of  all  engineering  activities,  consistency  of  implementation,  and  repeatable 
processes  are  mandatory  to  achieve  the  efficiency  required  in  the  short  schedules  of 
STOW-A  exercises 

6.7  Technology  Advancement  Issue  and  Recommendation 

Issue:  The  advancement  of  technology  is  such  that  new  products  are  announced,  on  the 
average,  every  18  months.  This  causes  rapid  obsolescence  of  expensive  equipment 
recently  procured  and  delivered  to  STOW-A  sites.  In  addition,  equipment  bought  for  the 
development  laboratory  environment  should  be  the  most  recent  available;  instead,  it  is 
frequently  the  oldest  that  has  been  bought  by  the  program.  The  program  also  runs  the 
risk  of  buying  immature  technology  and  defining/developing  new  interfaces  if  the  most 
newly  announced  systems  are  procured.  The  risk  associated  with  technology 
advancement  ties  back  into  the  requirement  definition  issue.  The  equipment  currently 
fielded  satisfies  the  exercise  goals  today,  i.e.,  supporting  brigade  level  exercises  with 
anticipated  virtual  entities  in  the  500  number  range.  If  the  requirement  for  larger 
numbers  is  specified  in  the  future,  improvements  in  hardware,  software,  and/or  system 
configuration  must  be  addressed. 
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Appendix  B 

STOWEX  96  Site  Survey  Checklist 

•  Facilities 

•  Floor  Plan  /  Layout 

•  Furniture 

•  Desks  /  table 

•  Chairs 

•  Stand  /  cart  /  shelving  for  large  screen  Stealth  monitors  (37”) 

•  Power 

•  Facilities  power 

•  Power  Distribution 

•  Outlet  Connectors 

•  Power  strips,  surge  protectors 

•  Network  Support 

•  DSI  node 

•  T20 

•  Video  Teleconferencing  (VTC) 

•  Telephone  Support  (Quality,  Quantity,  Location) 

•  Voice  (Exercise  /  Technical  Control,  Administrative,  etc.) 

•  Data  (BBS  Remotes) 

•  Fax 

•  Equipment  /  Software 

•  Local  Area  Network 

•  Ethernet  (10  Base  T)  hubs 

•  Ethernet  Transceivers 

•  1 0  Base  T 

•  Thinnet 

•  Fiber  optic 

•  Cables 

•  1 0  Base  T 

•  Thinnet 

•  Fiber  optic 

•  Audio  (SoundStorm) 
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•  Telephone 

•  Voice  Hardware 

•  Telephones  -  conference  call  capability 

•  Telephone  headsets 

•  Dial-up  Hardware  Support 

•  Mux’es 

•  Modems 

•  FAX  Machine 

•  Computers  /  Workstations  (class  of  SGI  machine,  RAM,  hard  drive  size,  #  of 
Ethernet  ports) 

•  COTS 

•  AG 

•  XCIAU 

•  Logger 

•  OPSIN 

•  STRIPES  (PVD) 

•  STRIPES  (3D) 

•  ModSAF  (Blue  and  Red  Forces) 

•  GFE 

•  BBS 

•  HICON,  Friend,  Enemy 

•  See-All 

•  AAR 

•  Data  Storage 

•  4mm  DAT  Tape  Drive 

•  QIC  Tape  Drive 

•  9GB  Disk  Drive 

•  CD-ROM  Drive 

•  Software 

•  Machine  Software  Configuration 

•  Operating  System 

•  NFS 

•  Ethernet  Driver  (AG,  XCIAU,  OPSIN) 

•  COTS  Software  Tools 

•  SGI  IDO 

•  SGI  C++ 

•  Internet  Suite 

•  FTP 

•  e-mail 

•  Purify 

•  Network  Analysis  Software 

•  GFE  Application  Software 

•  AG 

•  XCIAU 
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•  STRIPES 

•  Logger 

•  PVD 

•  3D 

•  ModSAF 

•  OPSIN 

•  BBS 
Other  Hardware 

•  Stealth  monitors 

•  Sound  Storm 

•  Remote  monitor 

•  Video  distribution  amplifier  (VDA) 

Other  Software 

•  SIMNET  /  AIRNET  Simulators 

•  Mapping  Files 

•  DED  Files 
Tools  and  Test  Equipment 

•  Network  Analyzer 

•  Cable  Tester 

•  Crimper 
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Appendix  C 


Mapping 

The  visual  models  for  the  SIMNET  simulators  are  stored  in  a  dynamic  element  database 
(DED).  Each  DED  provides  several  models,  each  with  a  database  unique  entity  ID.  This 
ID  is  used  by  the  simulation  to  display  a  particular  model.  Mapping  files  are  used  to 
identify  which  DED  entity  should  be  displayed.  The  SIMNET  simulators  utilize  three 
mapping  files  to  identify  the  correct  visual  models  to  display.  These  files  are:  the  vehicle 
mapping  file,  the  ammo  mapping  file,  and  the  “  asid”  mapping  file. 

The  vehicle  mapping  file  is  used  to  map  the  SIMNET  protocol  vehicle  type  enumerations 
to  the  appropriate  visual  model  in  the  DED.  The  ammo  mapping  file  is  used  to  map 
munitions  special  effects,  by  munition  type,  to  firing  and  detonation  events  within  the 
simulation.  The  asid  mapping  file  appears  to  be  for  holding  offsets  for  vehicle  special 
effects,  like  smoke,  flames,  and  bumper  numbers,  to  a  displayed  visual  model. 

In  support  of  the  STOWEX  96,  there  was  a  need  to  generate  a  new  vehicle  mapping  file 
for  the  SIMNET  Stealth,  Ml,  and  M2  simulators.  The  “standard”  SIMNET  ammo 
mapping  file  and  asid  mapping  file  were  used.  The  mapping  effort  reflected  the 
following: 

VEHICLE  MAPPING  FILE: 

1.  The  mapping  files  are  very  sensitive.  The  mapping  files  are  system  sensitive  and 
have  to  be  oriented  correctly.  A  mapping  file  on  and  Ml  may  not  work  on  M2  and 
the  same  for  a  file  on  a  M2  to  a  Ml.  Also,  if  you  transfer  a  mapping  file  using  FTP 
from  site  to  site,  make  sure  that  you  are  in  ASCII  mode.  If  you  transfer  in  binary 
mode  you  may  pick  up  certain  control  characters  that  will  crash  the  M2s.  (This  has  to 
do  with  the  butterfly  vs.  MassComp  vs.  147  hosts). 

2.  The  file  is  separated  into  several  sections  or  “classes”  of  vehicles  such  as 
“ armored_tracked”  or  “towed”.  Each  vehicle,  as  identified  by  its  SIMNET 
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enumeration,  must  be  placed  in  its  appropriate  class.  The  ModSAF  header  file 
“  veh_type.h”  contains  the  definition  of  vehicle  types  including  their  “class” . 

3.  If  entries  (as  defined  by  their  vehicle  number)  are  not  in  their  “class”,  it  appears  that 
the  SIMNET  simulators  will  crash. 

4.  If  entries  are  in  the  correct  class,  the  order  of  the  entries  will  not  matter.  It  is 
important  that  the  vehicles  be  in  the  correct  class  or  the  system  will  crash. 

5.  The  first  three  entities  in  each  section  or  “class”  are  the  default  entries  for  the  class. 
The  first  one  is  the  “other”  default.  The  second  one  is  the  “US”  default.  The  third  is 
the  “USSR”  default.  The  vehicle  number  is  not  important  for  these  entries. 

6.  Butterfly  systems  require  another  printable  ASCII  character  between  the  comment 
hash  mark,  “#”,  and  the  end  of  line.  Because  of  this,  “blank  line”  comments  should 
consist  of  “#  *”  instead  of  just  “#” .  Note  that  blank  lines  are  acceptable. 

7.  All  of  the  classes  must  be  in  the  reader  file,  otherwise  the  application  will  not  boot. 

8.  The  ModSAF  “  constants.rdr”  file  contains  the  SIMNET  enumeration  for  all  of  the 
entities  simulated  by  ModSAF. 

9.  The  ModSAF  entities  directory  contains  the  rdr  files  for  all  of  the  ModSAF  simulated 
entities.  In  each  of  these  files,  a  single  line  identifies  the  guises  for  the  entity.  This 
line  must  have  two  entries,  a  nominal  guise  and  an  alternate  guise.  The  guises 
identify  the  constants  placed  in  the  data  PDUs.  If  the  second  guise  is  not  in  place,  the 
SIMNET  simulators  will  crash  in  alternate  mode. 

10.  There  are  many  errors  in  several  ModSAF  rdr  files.  STOWEX  looked  at  the 
ModSAF  entities  files  and  the  constants  files  and  found  several  errors. 

1 1 .  A  typical  entry  in  the  vehicle  mapping  file  needs  to  look  like: 

STARTVEHJENTRY 
vehicle  28820802 

appearance_mask  0 

appearance  0 

cig_veh_type  43 

destroy  ed_type  50 

ENDVEHICLEENTRY 

12.  The  vehicle  number  and  the  appearance  mask  fields  are  in  hexadecimal.  The  rest  of 
the  fields  are  decimal.  Note  that  the  IG  generated  DED  listings  give  the  model 
numbers  in  hexadecimal. 
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13.  The  appearance  mask  field  is  a  mask  to  allow  the  use  a  different  visual  models  for 
different  appearance  enumerations. 

14.  The  appearance  field  should  be  0  (zero)  unless  some  other  information  becomes 
available. 

15.  The  IG  vehicle  type  and  the  destroyed  type  fields  contain  the  DED  entry  id  for  the 
“live”  and  “dead”  model  respectively. 

16.  Case  does  not  appear  to  be  important,  at  least  in  the  hexadecimal  vehicle  and 
appearance  mask  entries.  The  convention  for  each  entry  appears  to  be  uppercase  for 
the  “class”  headers,  including  the  start  and  end  vehicle  entry  headers,  and  lower  case 
for  the  entry  names. 

17.  Missiles  are  entities  and  therefore  their  visual  representation  is  in  the  DED;  their 
mapping  needs  to  be  in  the  vehicle  mapping  file  under  the  missiles  section.  Note  that 
muzzle  flashes,  detonations,  etc.  for  all  munitions  including  missiles,  are  contained  in 
the  ammo  mapping  file. 

18.  The  beachball  is  the  standard  default  model  built  in  the  DED.  The  flames  and  the 
smoke  are  special  effect  also  built  in  the  DED.  In  addition  to  the  beachball  standard, 
there  are  DEDs  without  flames  and  smoke.  (Supposedly,  the  Chodo  DED  was  built 
with  an  Ml  as  the  default  model  instead  of  the  beachball.) 

AMMO  MAPPING  FILE: 

1.  The  ammo  mapping  file  maps  muzzle  flash  and  detonation  visual  effects  (from  the 
DED)  for  all  munitions  including  ballistics  and  missiles.  Note  that  ballistic  munitions 
do  not  have  any  visual  representation  other  than  a  muzzle  flash  and  detonation  while 
missiles  are  represented  as  entities  (both  visually  and  in  PDUs). 

2.  The  ammo  mapping  file  typically  does  not  need  to  be  modified.  Most  DEDs  have  the 
“  standard”  special  effects  entries. 

3.  Note:  STOWEX  had  to  put  new  entries  into  the  XCIAU  “enttype.tbl”  to  translate 
“  unknown”  artillery  detonations  into  HE  detonations  so  that  they  could  be  “  seen”  by 
the  O/Cs. 

ASID  MAPPING  FILE: 

1.  Appears  to  hold  the  offset  for  vehicle  special  effects  such  as  smoke,  muzzle  flash, 
flames,  etc. 

SIM  DO  vs  CHODO  DED  Files: 
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The  SI  MIX)  PEP  file,  which  is  the  default  DEI),  was  generated  and  delivered  with  the 
SIMNET  systems.  SIMDO  contains  approximately  50  models.  The  Cl  101)0  DEI)  file, 
which  was  generated  to  support  training  in  Korea  (Chorvvon  database),  contains  17 
models.  Different  PEP  files  can  be  loaded  into  the  image  generator  to  meet  different 
training  needs. 


Prior  to  the  STOW  EX  mapping  task,  the  contractor's  recommendation  to  use  Cl  101)0 
was  made  and  agreed  upon  since  this  PEP  file  had  also  been  used  during  Prairie  Warrior 
95.  As  indicated  elsewhere  in  this  section,  the  mapping  testing  task  indicated  problems 
with  OPFOR  Rotary  Wing  Aircraft  (RWA).  Vehicle  mapping  files  used  in  conjunction 
with  the  CHODO  PEP  file  provided  an  OPFOR  RWA  that  visually  appeared  as  an  All- 
64  for  one  type  of  OPFOR  RWA  and  visually  appeared  as  OPFOR  ground  vehicles  for 
two  other  tvpes  of  OPFOR  RWA's.  In  an  attempt  to  overcome  the  lack  of  a  suitable 
OPFOR  RWA.  the  Cl-IODO  DEI)  replaced  a  version  of  SIMDO  available  at  Fort  Knox. 
While  this  version  of  SIMDO  may  have  provided  a  better  model  for  OPFOR  RWA.  it 
invalidated  the  mapping  test  previously  conducted. 


C-4 


ADST-II-CDRL-01 3R-9600220-BA 

1 8  Decembers  October  1996 


Table  C-l  3D  Blue  Ground  Vehicle  Model  Mapping 


ModSAF  3D 
Model 

Stealth  3D 
Model 

SIMNET  Ml 

SIMNET  M2 

Color 

Avenger 

HMMWV 

HMMWV  (TOW) 

HMMWV 

brown 

HMMWV 

HMMWV 

HMMWV  (TOW) 

HMMWV 

brown 

Outrider 

HMMWV 

Cargo  HEMMT 

Truck-Friend 

brown 

NLOS 

HMMWV 

HMMWV  (TOW) 

HMMWV 

brown 

GBS  FA AD 

HMMWV 

HMMWV  (TOW) 

HMMWV 

brown 

Ml 

Ml 

Ml 

Ml 

brown 

Ml  CPS 

Ml 

Ml 

Ml 

brown 

M1A1 

Ml 

Ml 

Ml 

brown 

M1A2 

Ml 

Ml 

Ml 

brown 

AVLB 

Ml  13 

Ml  13 

M113 

brown 

Grizzly 

Ml  13 

M113 

M113 

brown 

M2 

M2 

M2 

M2 

brown 

M3 

M2 

M2 

M2 

brown 

M3  A3 

M2 

M2 

M2 

brown 

LOSAT 

Ml  13  w/RL 

M113 

M113 

brown 

Stingray 

M2 

M2 

Ml 

brown 

M2  Stinger 

M2 

M2 

M2 

brown 

M102 

M109 

M109 

Self  Propelled 

brown 

M106A1 

M106 

M106 

Ml  06 

brown 

Ml  064 

M106 

M106 

M106 

brown 

M109 

M109 

Self  Propelled 

Self  Propelled 

brown 

M109A1 

M109 

Self  Propelled 

Self  Propelled 

brown 

M109A3 

M109 

Self  Propelled 

Self  Propelled 

brown 

M109A5 

M109 

Self  Propelled 

Self  Propelled 

brown 

M109A6 

M109 

Self  Propelled 

Self  Propelled 

brown 

Crusader  SPH 

M109 

Ml 

Ml 

brown 

Crusader  RSV 

HEMMT 

HEMMT 

CARGO 

TRUCK 

brown 

Crusader  M977 

HEMMT 

HEMMT 

CARGO 

TRUCK 

brown 

Ml  13  Ambulance 

M113A2 

M113 

ml  13 

brown 

Ml  13  Engineer 

Ml  13A2  w/ 

Ml 05  trailer 

Ml  13 

M113 

brown 

Ml  13  Observer 

M113A2 

Ml  13 

M113 

brown 

Ml  98 

Ml  09 

Self  Propelled 

Self  Propelled 

brown 

M270 

MLRS 

Ml  13 

MLRS  (Ml  13) 

Lt  green 

M270  GAT2 

MLRS 

Ml  13 

MLRS  (Ml  13) 

Lt  green 

M270  M26 

MLRS 

Ml  13 

MLRS  (Ml  13) 

Lt  green 

M577A1 

M577A1 

M113 

M113 

black 

M88 

M88 

M88 

M88 

brown 
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M977 

HEMMT 

HEMMT 

Cargo  HEMMT 

brown 

M978 

HEMMT 

HEMMT 

Cargo  HEMMT 

brown 

M979 

HEMMT 

HEMMT 

Cargo  HEMMT 

brown 

M981 

Ml  13  w/RL 

Ml  13 

Ml  13 

brown 

M992 

Ml  13 

Ml  13 

Ml  13 

brown 

XM8 

Ml 

Ml 

Ml 

brown 

M35A2 FDC 

M985  HEMTT 

HEMMT 

HEMMT 

brown 

Table  C-2  3D  Blue  Aircraft  Vehicle  Model  Mapping 


ModSAF  3D 
Model 

Stealth  3D 
Model 

SIMNET  Ml 

SIMNET  M2 

Color 

US  UAV 

US  UAV 

A-10 

A-10 

Lt 

green 

A10 

A10 

A-10 

A-10 

green 

F14D 

F14 

A-10 

A-10 

gray 

F16D 

F16 

A-10 

A-10 

brown- 

green 

AH64 

AH64 

AH64/RAH66 

Longbow? 

AH64/RAH66 

Longbow? 

green 

AH64D 

AH64 

AH64/RAH66 

Longbow? 

AH64/RAH66 

Longbow? 

green 

RAH66 

RAH66 

AH64/RAH66 

Longbow? 

AH64/RAH66 

Longbow? 

dark 

RAH  Longbow 

RAH66 

A1 164/RAI 166 
Longbow? 

AH64/RAH66 

Longbow? 

dark 

OH58D 

OH58 

AH64/RAH66 

Longbow? 

AH64/RAH66 

Longbow? 

black 

Table  C-3  3D  Red  Vehicle  Model  Mapping 


SECTIONS 

Stealth  3D  Model 

Color 

LOSAT  Section 

LAV25  (nothing) 

Crusader  Section 

nothing 
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Table  C-4  3D  Platoon  Model  Mapping 


PLATOONS 

Stealth  3D  Model 

Color 

Avenger  Platoon 

HMMWV 

brown 

Ml  Platoon 

Ml 

brown 

M1A2  Platoon 

Ml 

brown 

LOSAT  Platoon 

Nothing  (LAV  25) 

M2  Stinger  Platoon 

M2 

brown 

M3  Platoon 

M3 

brown 

M3A3  Platoon 

M3 

brown 

M3  Scout  Platoon 

M3 

brown 

XM8  Platoon 

Ml 09  (XM8) 

green 

Crusader  Platoon 

Radio 

Crusader  LRP 

Radio,  HMMWV,HEMMT 

brown 

Table  C-5  3D  Company  Model  Mapping 


Company 

Stealth  3D  Model 

Color 

Ml  Company 

Ml 

brown 

M1A2  Company 

Ml 

brown 

LOSAT  Reinforced  M2 

Co 

4  radio,  14  M2, 4  Ml 

brown 

M2  Reinforced  Company 

18  M2, 4  Ml,  4  Infantry 

brown  green 

Blue  Mech  Heavy  Co 

8  M2,  4  Ml,  8  Infantry 

brown  green 

Blue  Tank  Heavy  Co 

4  M2,  8  Ml,  4  Infantry 

Armored  Cav  Troop 

A  little  of  everything 
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Table  C-6  3D  Red  Ground  Vehicle  Model  Mapping 


ModSAF  3D 
Model 

Stealth  3D 
Model 

SIMNET  Ml 

SIMNET  M2 

Color 

BM21 

BM21  Rocket 
Launcher 

BMP 

BMP 

brown 

BMP1 

OK 

BMP 

BMP 

brown 

BMP2 

OK 

BMP 

BMP 

brown 

BRDM2 

OK 

BMP 

BMP 

brown 

BTR60PU 

OK 

BTR 

BTR 

brown 

BTR80 

OK 

BTR 

BTR 

brown 

SA9 

OK 

BRDM 

BRDM 

brown 

SA15 

OK 

BRDM 

BRDM 

brown 

T72M 

OK 

Tank 

Tank 

brown 

T80 

OK 

Tank 

Tank 

brown 

URAL375C 

Truck 

Truck 

Truck 

white 

URAL375F 

Truck 

Truck 

Truck 

white 

ZIL131  FDC 

Truck 

Truck 

Truck 

white 

ZSU23-4M 

OK 

ZSU 

ZSU 

green 

1V13 

OK 

BRDM 

BRDM 

brown 

1V14 

OK 

BRDM 

BRDM 

brown 

1V15 

OK 

BRDM 

BRDM 

brown 

1V16 

OK 

BRDM 

BRDM 

brown 

2B1 1  (2S1 1) 

2B11  (BMP) 

BRDM 

BRDM 

brown 

2S12 

OK 

Self  Propelled 

Self  Propelled 

brown 

2S1 

OK 

Self  Propelled 

Self  Propelled 

brown 

2S6 

OK 

Self  Propelled 

Self  Propelled 

brown 

2S19 

OK 

Self  Propelled 

Self  Propelled 

brown 

Table  C-7  3D  Red  Aircraft  Vehicle  Model  Mapping 


ModSAF  3D 
Model 

Stealth  3D 
Model 

SIMNET  Ml 

SIMNET  M2 

Color 

USSR  UAV 

SU25 

FWA 

FWA 

brown 

MIG  27 

OK 

FWA 

FWA 

brown  | 

MIG  29 

OK 

FWA 

FWA 

dk  blue 

SU25 

SU25 

FWA 

FWA 

brown 

Mi  8 

Hind-D 

ATK  HELO 

? 

brown 

Mi  24 

OK 

ATK  HELO 

? 

brown 

Mi  28 

Mi  28 

ATK  HELO 

? 

brown 

KA  50 

KA  50  (Hind-D) 

ATK  HELO 

? 

brown 
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Table  C-8  3D  Vehicle  Model  Mapping,  DIS  Simulators 


ModSAF 


avenger 


ARSI  Dial-a-Tank 


hmmvvv 


RCVS  HMMWV 


Ihmmwv 


RCVS  577 


Q36  Radar 


HMMWV 

hmmwv 

hmmwv 

hmmwv 

hmmwv 

outrider 

hmmwv 

hmmwv 

hmmwv 

nlos 

hmmwv 

hmmwv 

?? 

GBS  FAAD 

hmmwv 

hmmwv 

?? 

Ml 

Ml 

Ml 

Ml 

Ml 

Ml  CPS 

Ml 

Ml 

Ml 

Ml 

M1A1 

Ml 

Ml 

Ml 

Ml 

M1A2 

Ml 

Ml 

Ml 

Ml 

A  VLB 
GRIZZLEY 


M3  A3 


LOSAT 


STINGRAY 


M2  STINGER 


Ml  02 


M106A1 


Ml  064 


Ml  09 


M109A1 


Ml  09  A3 


M109A5 

M109A6 


CRUSADER  SPH 


CRUSADER  RSV 


CRUSADER  M977 


Ml  13 

AMBULANCE 


Ml  13  ENGINEER 


Ml  13  OBSERVER 


M198 


M270 

M270  GAT2 
M270  M26 


M577A1 


M88A1 


M977 


978 

979 


981 

992 


XM8 


M35A2-FDC 


USUAV 

A10 

IF14D 


ENTITY  MARKER 


TRACKED  VEH. 


TRACKED  VEH. 


TRACKED  VEH. 
TRACKED  VEH. 
TRACKED  VEH. 


Ml  13 


M2/M3 

M2 


M2 


M2 


Ml  13 


Truck 


M2 


Ml  13 


MLRS 


Ml  13 


?? 

M2 


M2 


M2 


Ml  13 


M2 

M2 _ 

Rkt  Lehr 
Ml  13 


Ml  13 


MLRS 


Ml  13 


Ml  13 


TRUCK 


TRACKED  VEH. 


M577 


ENTITY  MARKER  M88 


Cargo  Hemmt 


M577 


M88 


M977 


HEMMT 


Ml 


?? 

M2 


M2 


M2 


?? 


M2 


?? 


Rkt  Lehr 


Ml  13 


Ml  13 


?? 


?? 


Truck 

Truck 

M977 

M977 

truck 

M977 

Ml  13-AMB 

Ml  13-AMB 

Ml  13 

Ml  13 

Ml  13 

Ml  13 

MLRS/109 

MLRS/109 

FIST-V 
Ml  13 


Ml 


Truck 


A10 


A10 


F14 


Truck 


M977 


M977 

Ml  13-AMB 


Ml  13 


Ml  13 


?? 


MLRS 


M271 


273 

577 


M88 


M977 


HEMMT 


?? 

Ml  13 


Ml  13 


?? 


Truck 


UAV 


A10 


F14 
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F16D 


RAH66 


AH64 


AH64D 


RAH  66  LONGBOW 
OH58D 


BM21 


BMP1 


BMP2 


BRDM2 


BTR60PU 

BTR80 


SA9 


SA15 

T72M 


T80 

URAL375C 


URAL375F 


ZIL131FDC 
ZSU23_4M 
IV 1 3 


V 

V 

V 


2B1 1  (S21 1) 


2S12 


2S1 


2S6 

2S19 

USSR  UAV 


MIG27 
MIG29 
SU  25 


MI  8 


KA  50 


OH58 


ENTITY  MARKER 


Towed  Missile 
Launcher 


FI  4/Twin  Tail 


AH64 


AH64 


AH64 


AH64 


AH64 


Truck 


BRDM 


BMP 


BMP 

BMP 


I  ENTITY  MARKER 


BMP _ 

Tank 


Tank 

Green 

Green 


Tank  w/bumper# 
Tank  w/ZSU 


BMP 


BMP 


Tank 

Tank 


ik 

cl 

ci 


Truck 

Tank  w/ZSU 
BMP 


BMP 

BMP 

'  FWA-Single  Tail 


FWA 


FWA 

'  FWA-Single  Tail 


BMP 


BMP 


BMP 

SU25 


FWA-Twin  Tail 


FWA-Twin  Tail 


SU25 


HELICOPTER 
Atk  Helo 


Atk  Helo 


Atk  Helo 


k 

k 


Tank 


Tank 


Tank 

A10 


FWA-Twin  Tail 


FWA-Twin  Tail 


A10 


HELICOPTER 


Atk  Helo 
Atk  Helo 


Atk  Helo 


500  lb 


4.2  Mtr 


20001b 


105  mm  How 
155  mm  How 
MICLIC 


165  HEP 

yes 

yes 

yes 

MLRS 

yes 

yes 

yes 

Smoke  -  WP 

Saw  explosion 

Saw  explosion 

Saw  explosion 

Smoke  -  IIC  Red 

Saw  explosion 

Saw  explosion 

Saw  explosion 
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Flare  -  Parachute 


No 


No 


No 


Table  C-8  3D  Munitions 


Munition 

Stealth 

Ml  SIMNET 

RCVS 

DAT 

2000  Bomb 

No 

No 

yes 

yes 

500  Bomb 

Yes 

Yes 

yes 

yes 

M548 

Yes 

No 

yes 

yes 

4.2  Impact 

Yes 

Yes 

yes 

yes 

4.2  Proximity 

Yes 

Yes 

yes 

yes 

155  Impact 

Yes 

Yes 

yes 

yes 

155  Proximity 

Yes 

Yes 

yes 

yes 

165  HEP 

No 

No 

yes 

yes 

MLRS 

Yes 

Yes 

yes 

yes 

MICLIC 

Yes 

No 

yes 

yes 

Bridge  Remote  Detonation 

Yes 

Yes 

WP  Smoke  Ml  10E 

No 

No 

yes 

yes 

WP  Smoke  M825 

No 

No 

yes 

yes 

M76  IR  Smoke 

No 

No 

L8A1  RP  Smoke 

No 

No 

M18HC  -  Red 

No 

No 

M18HC- Green 

No 

No 

M18HC  -  Yellow 

No 

No 

M18HC- Violet 

No 

No 

TOW 

Yes 

Yes 

Yes 

Yes 

Songster 

Yes 

Yes 

Yes 

Yes 

Hellfire 

KB 

Yes 

Yes 

Yes 

Sagger 

Yes 

Yes 

Yes 

Spandrel 

Yes 

Yes 

Yes 

Gaskin 

Yes 

Yes 

Yes 

Yes 

Gauntlet 

Yes 

Yes 

Yes 

Yes 

Stinger 

Yes 

Yes 

Yes 

Yes 

SA19 

Yes 

Yes 

Not  Tested 

Not  Tested 

SA6 

Yes 

Yes 

Not  Tested 

Not  Tested 

MK82 

Yes 

Yes 

Yes 

Yes 

Maverick 

Yes 

Yes 

Yes 

Yes 

Sidewinder 

Yes 

Yes 

Not  Tested 

AT-6 

Yes 

Yes 

Yes 

Yes 
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VOICE  COMMUNICATION 
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CONFERENCE  CALL  INSTRUCTIONS 

General.  Ten-way  conference  calls  are  initiated  from  the  NSC’s  STOW-A  Exercise 
Control  /  Technical  Control  area  on  either  the  Exercise  Control  line  (913)  684-8312  or 
the  Technical  Control  line  (913)  684-8370.  Other  telephone  extensions  may  be  activated 
for  10-way  conferences  be  calling  the  DOIM  POC  Neal  Sleeve  (684-7009)  or  Diana 
Stanton  (684-4567).  When  all  parties  are  connected,  switch  to  hands-free  /  speaker  mode 
and  continue  the  conference.  Hang  up  to  end  the  conference  and  disconnect  all  parties. 

To  Initiate  a  Conference  Call 

Action 

1 .  Pick  up  the  handset  or  set  to  hands 
free  mode. 

2.  Dial  the  conference  call  Access 
Code:  *72 

3.  Dial  the  telephone  number  of  the 
conferee 

4.  Conferee  answers 

5.  Press  flash  once 

6.  Dial  the  conference  call  Access 
Code:  *72 

Adding  Additional  Conferees 

1 .  Press  flash  once 

2.  Dial  the  telephone  number  of  the 
conferee 

3.  Conferee  answers 

4.  Press  flash  once 

5.  Dial  the  conference  call  Access 
Code:  *72 

Repeat  for  all  additional  conferees  up  to  a  maximum  of  10  total  conferees  (9  remotes 
and  the  originating  telephone  extension. 

The  STOWEX  Technical  Control  personnel  will  initiate  the  Exercise  Control  and  the 
Technical  Control  calls  daily  per  the  published  schedule. 


Ringback  tone 


Conference 


Response 
Dial  Tone 

Special  Dial  Tone 

Ringback  tone 

Conference 
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TELEPHONE  DIRECTORY 


Exercise  Control  Numbers 


Fort  Riley  BBS  HICON 

98-(913)  784-5796 

PIN  992920 

Fort  Riley  XCIAU 

98-(913)  239-1514 

PIN  992920 

Fort  Rucker 

98-(334)  598-3066  ext  251 

PIN  992920 

Fort  Knox 

98-(502)  624-3667 

PIN  992920 

Fort  Knox  LRS 

98-(502)  942-5633 

PIN  992920 

Army  Simulation  Center 

98-(703)  697-5190 

PIN  992920 

Technical  Control  Numbers 


DSI NCC 

99-(913)  758-1358 

PIN  992920 

Fort  Leavenworth  AG 

98-(913)  684  8370 

PIN  992920 

Fort  Riley  AG 

98-(913)  239  1290 

PIN  992920 

Fort  Riley  HICON  area 

98-(913)  784  5793 

PIN  992920 

Fort  Knox  AG 

98-(942)  942-1092  ext  617 

PIN  992920 

Fort  Rucker  AG 

98-(334)  598-3006  ext  234 

PIN  992920 

Command  and  Control 


STOWEX  96  Exercise  Director  -  LTC  Jim  Connelly  (Fort  Riley)  - 
STOWEX  96  Technical  Director  -  LTC  Mike  Kwan  (NSC)  - 
STOWEX  96  Technical  Advisor  -  Tom  Lasch  (STRICOM)  - 
Fort  Riley  POC  -  George  Eads  -  (913)  239-1492 
Fort  Knox  POC  -  LTC  Skip  Wentz  -  (502)  624-7558 
Fort  Rucker  POC  -  MAJ  A1  Huber  (334)  225-9731 

National  Simulation  Center,  Fort  Leavenworth,  KS 

Technical  Control  (913)  684-8370  (conference  call);  684-8364 
Exercise  Control  (913)  684-8312  (conferences  call);  684-8369 
Visitor  Center  (913)  684-8366 
BBS  Support  Team,  CUBIC  (913)  684-8455 

POCs 

SFC  Hunter  (913)  684-8311 
FAX  (913)  684-8427 

Mounted  Warfare  Test  Bed,  Fort  Knox.  KY 

Technical  Control  (AG)  -  (502)  942-1092  ext  617 
Exercise  Control  (LRS)  -  (502)  942-5633 
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POCs 

Mike  Krages  (502)  942-1092 
Eb  Kieslich  (502)  942-1092 
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TELEPHONE  DIRECTORY  -  Cont. 
SIMNET  Training  Center,  Fort  Knox,  KY 

Exercise  Control  (ModSAF)  -  (502)  624-3667 
POCs 

Jeff  Skilling  (502)  624-8066 

Battle  Simulation  Center  (BSC),  Fort  Riley,  KS 

Technical  Control  (HICON  area)  -  (913)  784-5793 
Technical  Control  (AG)  -  (913)  239-  1290 
Exercise  Control  -  (913)  784-5796 

POCs 

George  Eads  -  (913)  239-1492 
FAX  (913)  239-1491 


Aviation  Test  Bed,  Fort  Rucker,  Al. 

Technical  Control  (334)  598-  3066  ext  234 
Exercise  Control  (334)  598-  3066  ext  251 

POCs 

John  Lowry,  Operations  (334)  598-3066 
Glen  Hicks,  Technical  (334)  598-3066 
FAX  (334)  598-5370 


Army  Simulation  Center  tASCL  Pentagon 

POCs 

John  Ferguson  (703)  695-1267 


DSI  Customer  Service  Center 


DSI NCC  (913)  758-1358 
Help  Desk  l-(800)  259  9660 
FAX  (703)  243-8290 

Other  Administrative  Numbers 
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Network  Control  Site  (NCS)  for  Tactical  Communications 
MSG  Sonnier  DSN  856-1512,  Comm  (913)239-1512 
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BSC  Work  Cells  Telephone  Numbers 
1913)  239-xxxx 


Function 

Phone 

HICON 

1293 

EXCON 

1512 

OPFOR 

1294 

AAR  Prep 

1408 

AAR  Room 

1496 

Division  Response 
Cell 

1509/1510 

BDE  CDR 

1296 

2-34  AR 

1299 

1-16  IN 

1401 

101  FSB  BSA 

1402 

1-5  FA 

1403 

BDE  Control 

1404/  1405 

Task  Force  CSS 

1292 

Analyst  Area 

1295/  1407/  1503 

OC  Area 

1409, 1410 

BCTP  OPS 

1501, 1504 

Fax  - 1497 

STOWEX 

1505,  1506 

NCS 

1513 

BSC  Work  Cells  Telephone  Numbers 
(913)  784-xxxx 


Function 

Phone 

STRIPES 

5808 
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Tactical  Communications  RT31  Interface 
Telephone  Numbers 


Site 

Network 

Phone  Number 

Fort  Riley 

Command  Net 

Comm  (913)  784-6067 

O&I  Net 

Comm  (913)  784-6076 

A&L  Net 

Comm  (913)  784-6014 

FS  Net 

Comm  (913)  784-6093 

Spare 

Comm  (913)  784-6074 

Fort  Knox 

- 

“ 

Command  Net 

DSN  464-8782 

Comm  (502)  624-8782 

O&I  Net 

DSN  464-8778 

Comm  (502)  624-8778 

A&L  Net 

DSN  464-8785 

Comm  (502)  624-8785 

FS  Net 

DSN  464-8786 

Comm  (502)  624-8786 

IFSAS 

DSN  464-8782 

Comm  (502)  624-8782 

Fort  Rucker 

- 

- 

Command  Net 

(334)  598-1382 

O&I  Net 

(334)  598-1380 

A&L  Net 

(334)  598-1383 
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RT31  User  Instructions 


The  NCS  (Network  Control  Site)  located  at  the  BSC  in  Fort  Riley  will  initiate  the 
conference  telephone  calls  linking  Fort  Knox  and  Fort  Rucker  with  the  tactical 
communication  network.  The  NCS  will  initiate  the  Command  net,  the  O&I  net,  the  A&L 
net  and  the  FS  net. 

RT3 1  users  at  all  sites  will  perform  the  following  steps  in  establishing  each  of  the  tactical 
networks: 

1.  Locate  RT31’s  in  work  cell  sufficiently  separated  that  audio  feedback  will  not 
occur  (typically  3-4  feet). 

2.  Adjust  the  RT-3 1  volume  control  to  midrange. 

3.  Verify  that  transmit  (TX)  and  intercom  (unmarked)  lights  are  off.  If  the  intercom 
light  is  illuminated,  toggle  the  front  panel  switch. 

4.  When  the  NCS  initiated  call  is  received,  pick-up  the  commercial  phone  handset. 

5.  Upon  establishing  the  voice  connection  on  the  commercial  phone,  disconnect  the 
handset. 

6.  Adjust  RT31  volume  control  as  required. 

RT31  users  will  perform  the  following  steps  during  communication: 

1 .  Tactical  communication  network  reception  is  played  through  the  RT3 1  speaker. 

2.  To  transmit  on  the  network,  pick  up  RT31  handset  and  key  the  push-to-talk  (PTT) 
button.  Note  -  During  transmission  ,  the  transmit  light  (TX)  is  illuminated. 


D-10 


ADST-II-CDRL-01 3R-9600220-BA 

18  Decembers  Qett>ber  1996 


Communication  Bubble  Diagrams 


Figure  D-l  Operational  and  Intelligence  Network 
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Figure  D-2  Administrative  and  Logistics  Network 
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Note:  This  block  diagram  is  provided  for  informational  purposes  only. 
The  FS  Digital  Network  was  not  implemented  for  STOWEX  96. 


TACTICAL  TERMINA1 
ADAPTER 


Figure  D-4  Fire  Support  Digital  Net 


D-14 


ADST-II-CDRL-01 3R-9600220-BA 

1 8  December?  October  1996 


D-15 


ADST-II-CDRL-0 1 3R-9600220- B  A 


1 8  Decern  berA 


^  1996 


Figure  D-6  Technical  Control  Voice  Communications 
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Signal  Operating  Instructions  and  Radio  Telephone 
Operating  Procedures 


Pro-Words: 

OVER:  used  to  momentarily  pass  control  of  the  net  to  the  sender  /  receiver  and  to 
notify  the  distant  party  your  transmission  is  complete 

OUT:  closes  the  transmission.  The  party  originating  the  transmission  closes  the 
transmission  with  “  OUT” .  The  pro-word  “  OUT”  is  never  used  in  conjunction  with 
“OVER”. 

MORE-TO-FOLLOW :  used  by  the  sender  to  indicate  either  a  pause  in  a  message  or 
that  more  information  will  immediately  follow. 

BREAK:  used  to  indicate  a  separation  between  the  header,  body  text  and  footer  in  a 
transmitted  message. 

SAY  AGAIN:  used  by  the  receiver  to  request  clarification  if  a  message  is  not  received 
clearly.  Format:  “  Say  again  after. . . ,  Say  again  before. . ..” . 

I  SPELL:  used  to  insure  message  clarity  when  difficult  words  or  place  names  are 
contained  in  a  text  message.  Format:  I  SPELL  Cho  Won,  Charlie,  Hotel,  Oscar, 
Whiskey,  Oscar,  November. 

WILCO  (Will  Comply):  acknowledges  receipt  of  a  message  with  a  tasking  or  order. 

ROGER:  informs  the  sender  that  a  message  is  affirmed. 

WAIT  ONE:  indicates  to  sender  to  stop  transmission  momentarily,  and  then  proceed. 

WAIT  OUT:  indicates  to  sender  that  receiver  cannot  receive  the  message  at  this  time 
and  ends  the  transmission. 
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Video  Teleconferencing 

Video  teleconference  (VTC)  is  performed  at  each  of  the  STOWEX  96  sites  utilizing  a 
PICTURETEL  VTC  suite  interfacing  the  Defense  Simulation  Internet  (DSI).  STOWEX 
96  is  using  the  “Dual  Homing”  feature  of  the  DSI  to  provide  VTC  capability  as  well  as 
to  provide  an  alternate  path  for  data  streams  (should  the  primary  path  become 
inaccessible).  If  the  primary  data  path  (exercise  data  stream)  goes  down  when  a  VTC 
session  is  taking  place,  priority  is  given  to  the  training  exercise  and  exercise  data  streams 
are  transfer  to  the  alternative  data  path.  The  “  Dual  Homing”  feature  is  installed  at  the 
NSC  (Fort  Leavenworth),  the  BSC  (Fort  Riley),  and  the  SIMNET  Training  Center  (Fort 
Knox).  The  Army  Simulation  Center  (ASC)  and  the  Aviation  Test  Bed  (Fort  Rucker)  can 
access  either  the  exercise  data  streams  or  the  VTC  session  but  not  both  concurrently. 

Exercise  Control  at  the  BSC  (Fort  Riley)  will  serve  as  the  Net  Control  Station  (NCS)  or 
“moderator”  for  multi -point  conferences  to  each  site.  A  “moderated”  conference 
controls  who  has  the  floor  or  view,  rather  than  each  site  controlling  its  own  view.  VTC 
events  and  a  time  window  in  which  the  conference  is  expected  to  be  conducted  are  listed 
below: 


Date 

Event  Window 

Event 

3  Sept. 

1000-  1200 

Rehearsal 

3  Sept. 

1400-  1900 

OC  meeting 

4  Sept. 

1300-  1600 

BDE  FRAGO 

4  Sept. 

1600-  1900 

AAR  1 

5  Sept. 

1300-  1600 

TF  1-34  Brief  Back 

6  Sept. 

1500-  1900 

AAR  2 
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VTC  Moderator  Check-list 

(extracted  from  the  DSI  Operating  Procedures  Course  *) 


1 .  Prior  to  the  scheduled  VTC,  ping  each  of  the  participant’s  SUN  workstation. 

2.  Ensure  that  all  sites  participating  in  the  VTC  have  logged  in  to  their  SUN 
workstations  and  Vteam  is  up  and  running. 

3.  Initiate  the  talk  command  between  the  sites.  (You  will  have  to  open  a  new 
window  for  each  site). 

4.  Configure  the  codec  for  point  to  point  or  multipoint 

5.  At  the  scheduled  conference  time,  start  Vteam. 

*  Reference  chapter  5  of  the  DSI  Operating  Procedures  Course  for  detailed 
instructions  for  system  installation  and  configuration. 
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TCP/IP  Addressing 


Table  D-l  DIS  TCP/IP  Application  Gateway  Addresses 


AG 

IP  Address 

National  Simulation  Center  (NSC) 

164.217.15.2 

Fort  Riley 

164.217.213.2 

Fort  Knox 

164.217.2.2 

Fort  Rucker 

164.217.4.2 

Army  Simulation  Center  (ASC) 

164.217.197.2 

Table  D-2  NSC  IP  Addresses 


Equipment 

IP  Address 

AG  -NSC  (DIS) 

164.217.15.2 

AG  to  XCIAU1 

192.9.199.3 

XCIAU1  to  AG 

192.9.199.2 

XCIAU1  to  Main  DIS  Network 

192.9.201.2 

Tech  Control  PVD  to  Main  DIS  Network 

192.9.201.15 

Tech  Control  Logger  to  Main  DIS  Network 

192.9.201.16 

Tech  Control  Stealth  to  Main  DIS  Network 

192.9.201.17 

Tech  Control  Sound  to  Main  DIS  Network 

192.9.201.18 

XCIAU2  to  Main  DIS  Network 

192.9.201.3 

XCIAU2  to  BBS 

192.9.200.3 

OPSIN  to  BBS 

164.217.20.10 

OPSIN  to  ModSAF 

192.9.200.10 

BBS  -  ModSAF  1 

192.9.200.11 

BBS  -  ModSAF2 

192.9.200.12 

BBS  -  ModSAF 3 

192.9.200.13 

BBS  -  ModSAF4 

192.9.200.14 

BBS  -  ModSAF 5 

192.9.200.15 

BBS  -  ModSAF6 

192.9.200.16 

BBS  -  ModSAF 7 

192.9.200.17 

BBS  -  ModSAF 8 

192.9.200.18 

BBS  -  ModSAF9 

192.9.200.19 

BBS -ModSAF  10 

192.9.200.20 

ModSAF  Frontend 

192.9.200.21 

XCIAU3  to  Main  DIS  Network 

192.9.201.5 

XCIAU  to  Visitor  Center  DIS 

192.9.222.15 

STRIPES  PVD  to  Visitor  Center  DIS 

192.9.222.10 

STRIPES  3D  to  Visitor  Center  DIS 

192.9.222.11 

Sound  Storm  to  Visitor  Center  DIS 

192.9.222.12 
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Table  D-3  DIS  TCP/IP  Application  Gateway  Addresses 


AG 

IP  Address 

National  Simulation  Center  (NSC) 

164.217.15.2 

Fort  Riley 

164.217.213.2 

Fort  Knox 

164.217.2.2 

Fort  Rucker 

164.217.4.2 

Army  Simulation  Center  (ASC) 

164.217.197.2 

Table  D-4  Fort  Rucker  IP  Addresses 


Equipment 

IP  Address 

AG-XCIAU1 

192.9.202.2 

XCIAU1  -  AG 

192.9.202.3 

XCIAU  -  DIS 

192.9.203.3 

LAA 

192.9.202.4 

Logger 

192.9.202.5 

Table  D-5  Fort  Knox  IP  Addresses 


Equipment 

IP  Address 

AG  -  XCIAU  1 

192.9.208.2 

XCIAU  1  -  AG 

192.9.208.3 

XCIAU  -  DIS 

192.9.209.3 

LAA 

192.9.208.4 

Logger 

192.9.208.5 

Table  D-6  Fort  Riley  IP  Addresses 


Equipment 

IP  Address 

AG  -  XCIAU  1 

192.9.240.2 

XCIAU  1  -  AG 

192.9.240.3 

XCIAU  -  DIS 

192.9.241.3 

Logger 

192.9.240.4 

PVD 

192.9.241.10 

Stealth 

192.9.241.11 

Sound  Storm 

192.9.241.12 

Table  D-7  ASC  IP  Addresses 


Equipment 

IP  Address 

AG- XCIAU  1 

XCIAU  1  -  AG 

XCIAU  -  DIS 

Logger 

PVD 

Stealth 

Sound  Storm 
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a. 


b. 


Tactical  Communications 
Radio  /  Telephone  Interface 

Cable  -  Interface  between  the  TP-8  Tone  Panel  and  the  RT  -1029  mount  a  modified 
CX  4723.  This  cable  will  be  modified  into  a  “Pigtail”  with  the  following  pinout  at 
the  connector  (remaining  wires  not  used): 

Connector  Pin  Wire  Color  Definition  on  RT1029 

A  Black  Ground 

S  White  on  Red  Push  to  Talk 

U  Red  on  White  MIC 

K  White  on  Blue  RX  In 

Cable  to  TP-8  Interface. 

(1)  Connect  CX4723  to  the  terminal  strip 


J22  Connector  on  RT1029  mount 


TP-8 


Definitions:  4  =  Ground 

5  =  Push  to  Talk  (Tone  burst  received  from  RT-31  keys  RT-524) 

6  =  Mic  (Audio  TX  to/from  RT-524) 

7  =  RX  in  (Audio  RX  to/from  RT  524) 
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(2)  Connect  DCO  and  power  lines. 


NOTE:  It  is  recommended  that  a  “C”  block  be  mounted  to  the  TP-8  to 
provide  easy  installation  to  DCO. 
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Notes:  R17,  R1 8  and  R24  are  used  to  adjust  levels  coming  from  the  RT-3 1 
R22  and  R23  are  used  to  adjust  levels  coming  from  the  RT-524 
R30  adjusts  the  tone  burst  from  the  RT-3 1  which  keys  the  radio 


c.  RT-3 1  Intercom  Telephone. 

(1)  Disconnect  spring  on  hook  switch  inside  the  intercom  to  allow  receive  audio 
while  hand  set  is  off  hook. 

(2)  Adjust  “Pot’s”  as  shown: 
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Front  of  RT-31 
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Appendix  E 


Shipping  Data 
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Table  E-l  STOWEX  96  Shipping  List,  Fort  Leavenworth 


NSC 

Indigo2  Maximum  Impact 
w/keyboard  and  monitor 

LM00685 

STRIPES  3D 

R10000,  64MB,  2GB,  Additional 

192MB  installed,  IRIX  6.2,  4MB  texture 
memory  installed,  ICO  not  received 

NSC 

Spaceball 

LM00787 

NSC 

Mitsubishi  monitor 

LM00672 

NSC 

Mitsubishi  monitor 

LM00949 

NSC 

Mitsubishi  monitor 

LM00956 

NSC 

Indigo2  Solid  Impact 
w/keyboard  and  monitor 

LM00703 

Farm  PVD 

R10000,  64MB,  2GB,  Additional  64MB 
installed,  Additional  128MB  installed; 
IRIX  6.2 

NSC 

Indigo2  Solid  Impact 
w/keyboard  and  20”  monitor 

LM00700 

Farm 

R 10000,  64MB,  2GB,  Additional  64MB 
installed,  IRIX  6.2 

NSC 

Indigo2  Solid  Impact 
w/keyboard  and  20"  monitor 

LM00724 

Farm 

R10000,  64MB,  2GB,  Additional  64MB 
installed,  IRIX  6.2 

m 

Indigo2  Solid  Impact 
w/keyboard  and  20"  monitor 

LM00681 

spare 

R 10000,  64MB,  2GB,  Additional  64MB 
installed,  IRIX  6.2 

m 

Indigo2  Solid  Impact 
w/keyboard  and  20"  monitor 

LM00721 

Farm  spare 

R 10000,  64MB,  2GB,  Additional  64MB 
installed,  IRIX  6.2 

NSC 

Deskside  Onyx  w/keyboard  and  21"  monitor 

STRIPES  3D 

64MB,  2GB  RE2,  Additional  64MB 
installed,  16MB  texture  memory,  IRIX 
6.2,  MCO  BOB 

NSC 

Spaceball  (hold  until  AcuSoft  is 
finished) 

NSC 

Mitsubishi  monitor 

LM00667 

NSC 

Mitsubishi  monitor 

LM00670 

NSC 

Mitsubishi  monitor 

LM00671 

NSC 

Indigo2  w/keyboard  and  20" 
monitor 

SGI  loaner 

NSC 

Indigo2  w/keyboard  and  20" 
monitor 

SGI  loaner 

NSC 

(7)  50'  RGB  cables 

n/a 

NSC  (1)  13  W3  Amplifier  LM00964 

NSC  (2)  13W3  Adapters _ n/a _ 

NSC  (1)  transceiver  n/a 
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Table  E-2  STOWEX  96  Shipping  List,  Fort  Riley 


Indigo2  Maximum  Impact 
w/keyboard  and  monitor 

LM00686 

STRIPES  3D 

R10000,  64MB,  2GB,  Additional 

192MB  installed,  4MB  texture  memory 
installed,  ICO  not  received;  IRIX  6.2 

Riley 

Spaceball 

LM00785 

Mitsubishi  monitor 

LM00668 

Riley 

Mitsubishi  monitor 

LM00669 

Riley 

Mitsubishi  monitor 

IHIUM 

Indigo2  20"  monitor 

Indigo2  w/keyboard  and  20" 
monitor 

LM00905 

STRIPES  PVD 

R4400,  64MB,  2GB,  Additional  64MB 
installed,  Oracle  installed;  IRIX  5.3 

MM 

CD  ROM  Drive 

LM00947 

9GB  Drive 

LM01012 

IHtM 

4mm  Tape  Drive 

LM01011 

Riley 

Indigo2  w/keyboard  and  20" 
monitor 

LM00903 

Logger 

R4400,  64MB,  Additional  64MB 
installed,  IRIX  5.3 

Riley 

Indigo2  w/keyboard  and  20" 
monitor 

LM00902 

XCIAU-1 

R4400,  128MB,  2GB,  IRIX  5.3,  Dual 
Ethernet  card  installed 

Riley 

Indigo2  w/keyboard  and  20" 
monitor 

LM01005 

AG 

R4400,  64MB,  2GB,  IRIX  5.3,  Dual 
Ethernet  card  installed 

Riley 

spool  lOBaseT  cable 

n/a 

Riley 

crimp  tool 

n/a 

Riley 

(15)  speaker  phones 

Riley 

(15)  telephones 

Riley 

(15)  headsets 

Riley 

connectors 

Riley 

2  Transceivers 

n/a 

Riley 

(4)  75’  RGB  cables 

n/a 

Riley 

13W3  Amplifier 

LM00963 

Riley 

(2)  13W3  Adapters 

n/a 

Riley 

(8)  Surge  protectors 

n/a 

Riley 

spool  lOBaseT  cable 

n/a 

Riley 

crimp  tool 

n/a 

Riley 

VDA 

LM01106 

MM 

8  port  hub 

131  EMU 

8  port  hub 

nufaM 

4mm  tapes 

Riley 

(7)TP-8s5  RT-31s 

(drop  ship  to  site) 

Riley 

(5)  RT-31s 

(drop  ship  to  site) 
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Table  E-3  STOWEX  96  Shipping  List,  Other  Sites 


Site 

Equipment 

Tag 

Function 

Fort  Knox 

(10)  Speakerphones 
(10)  Telephones 

n/a 

Communications  Support 

(10)  Headsets 
(20)  RT-31s 

(drop  ship  to  site) 

Fort  Rucker 

(5)  Speaker  phones 
(5)  Telephones 

n/a 

Communications  Support 

(5)  Headsets 
(15)  RT-31s 

(drop  ship  to  site) 

Pentagon 

1  Ethernet  card 

1  CD  ROM  (Ethernet  driver) 
3  50”  RGB  cables 

2  15’  lOBaseT  cables 

1  64  MB  kit 

n/a 

Network  Support 

Table  E-4  STOWEX  96  Site  Addresses  and  Points  of  Contact 


Site 

Address 

Points  of  Contact 

Fort  Leavenworth 

National  Simulation  Center 

Building  45 

410  Kearney  Avenue 

Fort  Leavenworth,  KS  66027 

LTC  Michael  Kwan 

Captain  (P)  Jerry  Bastian 

SFC  Thom  Hunter 

Fort  Riley 

Commander,  Fort  Riley  Kansas 

Building  8388 

Fort  Riley,  KS  66442 

George  Eads  (Government) 
Steve  Bachelor  (Cubic) 

Fort  Knox 

Mounted  Warfare  Test  Bed 

Building  2021 

Black  Horse  Regiment  Avenue 

Fort  Knox,  KY  40121 

Dennis  Goard  (Logistics), 

Don  Appier  (site  manager), 
Mike  Krages,  Eb  Kieslich 

Fort  Rucker 

Aviation  Test  Bed 

Comer  Nighthawk  &  3rd  Avenue 
Building  5101 

Fort  Rucker,  AL  36362 

John  Railsback  (Receiving), 
John  Lowry,  Operations; 

Glen  Hicks,  Technical 

Pentagon 

DAMO-ZAS 

Deputy  Chief  of  Staff  Operations  & 

Plan 

400  Army  Pentagon 

Washington  DC  20310-0400 

Lockheed  Martin 

John  Ferguson  (COLSA), 

Jerry  Stueve,  Lockheed 
Martin 

E-4 


ADST-II-CDRL-01 3R-9600220-BA 

18  December?  October  1996 


Figure  E-l  Fort  Riley  Equipment  Shipment 
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lndigo2 


API  000 

OPSIN 

ndigo2  Maximum  Impact 

37"  Mitsubishi  Monitors 


Spaceball 


IP  FROM  OSF  TO  MSClt 


Bon  owed  SGi  250MHz  ^ 4400 

a  Jditional  123MB 
ir  stall  4GB  drive? 


BNC-4-50ft  high  res  RGB  cables 

Status  ship  trom  OSF  to  NSC 


I  R10000,  64  MB  2GB 
I  Addtronal  192  MB  installed 

14  MB  texture  memory  installed 
ICO  no*  received 
IRIX  6  2 
LM00685 

Status  received  ship  from  OSF  to  NSC 


lndigo2  Solid  Impact 


R10000  64MB 
Additional  64  MS 
Additional  126MB 
IRIX  6  2 

LM00703 


Status  received,  s 


Solid  I LM00700 
lr|  Solid  | 
Impact 

fs 

Slrv 

H  111 


Spares 
Solid  [  LM0°721 
‘  Solid  |  iMooeat 
Imftjict 


H  III 


Status  STA0062  7  ordered  and  received 
5  in  place  at  NSC 

Ship  4  from  OSF  to  NSC  (66  &  7  plus  2  Spares) 


24  Port  lOBaseT  Hub 


1  spool  lOBaseT  1000’ 


Source  BOM  Li  4 
Function  network  ca 
Status  STA054  past 


lndigo2 


Status  received,  to  be  shipped  trom  OSF  to  NSC 


Spare 


Borrowed  SGI  250MHz  R4400 


Status  ship  from  OSF  to  Riley 


4mm 

Tape 

Drive 


Adapter 

-|SY13W3|- 


BNC-4-50ft  high  res  cable 


Adapter 


ship  from  OSF  to  NSC 


37"  Mitsubishi  Monitors 


Spaceball 


Deskside  Onyx 


SGI 

lab 

—1  Max  Impact 

lab 

— 5  Solid  Impacts 

GFE  room 

— 2  lndigo2  loaners 

lab 

—1  Onyx  w/MCO  BOB 

lab 

—1  21"  monitor  (Onyx) 
—0  20"  monitors 

lab 

1  Spaceball 

6  37"  Mitsubishi  Monitors 

GFE  rack 
GFE  rack 
GFE  rack 
GFE  rack 
GFE  rack 


1  Transceiver 

1  Intel  card 
7  50'  RGB  cables 

2  13W3  Adapters 
1  13W3  Amplifier 

lab  Surge  protectors 

GFE  room  24  port  hub 
GFE  rack  crimp  tool 
GFE  room  connectors 
GFE  rack  cable  spool 
lab  4mm  DAT  drive 


Figure  E-2  Fort  Leavenworth  Equipment  Shipment 
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Appendix  I 

STOWEX  96  Equipment  Disposition 


ITEM 

PRESENT 

PROCESSOR 

BUMPER 

FUNCTION 

SOURCE 

FINAL 

LOCATION 

TYPE 

NUMBER 

LOCATION 

MAX  IMPACT 

ASC 

R10K 

LM00686 

STRIPES  3D 

STOWEX 

ASC 

12  PORT  10-BASE-T 

AVTB 

A24065 

NETWORK 

PW95- 

AVTB 

AVTB 

12  PORT  10-BASE-T 

AVTB 

A24066 

NETWORK 

PW95- 

AVTB  : 

AVTB 

4MM  DAT 

AVTB 

A23641 

LOGGER 

PW95- 

AVTB 

PERIPHERAL 

AVTB 

5  x  SPEAKER 

AVTB 

NONE 

COMMS 

STOWEX 

AVTB 

PHONES 

8  PORT  10-BASE-T 

AVTB 

A24080 

NETWORK 

PW95- 

AVTB 

AVTB 

9  GB  HD  DRIVE 

AVTB 

A23650 

LOGGER 

PW95- 

AVTB 

PERIPHERAL 

AVTB 

CD  ROM  DRV 

AVTB 

A23658 

PERIPHERAL. 

PW95- 

AVTB 

AVTB 

INDIGO  2 

AVTB 

R4400 

A23680 

AG 

PW95- 

AVTB 

AVTB 

INDIGO  2 

AVTB 

R4400 

A24001 

OTHER 

PW95- 

AVTB 

AVTB 

INDIGO  2 

AVTB 

R4400 

A24013 

LAA 

PW95- 

AVTB 

AVTB 

INDIGO  2 

AVTB 

R4400 

A24019 

CIAU 

PW95- 

AVTB 

AVTB 

INDIGO  2 

AVTB 

R4400 

A24022 

LOGGER 

PW95- 

AVTB 

AVTB 

QIC  1/4'  TAPE  DRV 

NSC 

A23838 

PERIPHERAL 

PW95- 

AVTB 

AVTB 

INDIGO  2 

NSC 

R4400 

A23659 

BLUE  MODSAF 

PW95- 

LWTB 

LWTB 

INDIGO  2 

NSC 

R4400 

A23683 

BLUE  MODSAF 

PWS5- 

LWTB 

LWTB 

INDIGO  2 

NSC 

|  R4400 

A23692 

BLUE  MODSAF 

IPW95- 

LWTB 

LWTB 

10  x  SPEAKER 

MWTB 

COMMS 

STOWEX 

MWTB 

PHONES 

12  PORT  10-BASE-T 

;  MWTB 

A23S33 

NETWORK 

PWS5 

MWTB 

4MM  DAT 

MWTB 

A23643 

LOGGER 

STOWEX 

MWTB 

PERIPHERAL 

8  PORT  10-BASE-T 

MWTB 

A24082 

NETWORK 

PW95 

MWTB 

9  GB  HD  DRIVE 

MWTB 

A23853 

LOGGER 

PW85 

MWTB 

PERIPHERAL 

CD  ROM  DRV 

MWTB 

A23655 

PERIPHERAL 

PW95 

MWTB 

1-1 


ADST-II-CDRL-01 3R-9600220-BA 

1 8  Decembers  ■■October  1996 


INDIGO  2 

MWTB 

R4400 

A23577 

LOGGER 

PW95- 

MWTB 

MWTB 

INDIGO  2 

MWTB 

R4400 

A23604 

AG 

PW95- 

MWTB 

MWTB 

INDIGO  2 

MWTB 

R4400 

A23613 

CIAU 

PW95- 

MWTB 

MWTB 

INDIGO  2 

MWTB 

R4400 

A23616 

LAA 

PW95- 

MWTB 

MWTB 

QIC  1/4' TAPE  DRV 

MWTB 

A23637 

PERIPHERAL 

PW95 

MWTB 

12  PORT  10- BASE*! 

NSC 

A23575 

network 

PW95 

NSC 

3012T-12  PORT 

NSC 

A24076 

CENTRECOM  HUB 

PW95 

NSC 

3012T-12  PORT 

NSC 

A24074 

CENTRE  COM  HUB 

FW95 

r  Nsc 

3012T-12  PORT 

NSC 

A24068 

CENTRECOM  HUB 

PWS5 

NSC 

3024TR-24  PORT 

NSC 

LM 00980 

CENTRECOM  HUB 

STOWE  X 

NSC 

13W3DA2 

NSC 

LM00964 

AMPLIFY  VIDEO 

STOWEX 

NSC 

AMP/SPLITTER 

SIGNAL 

20"  SGI  RGB 

NSC 

A23570 

BLUE  MODSAF 

PW95 

NSC 

MONITOR 

20"  SGI  RGB 

NSC 

A23579 

SAFSIM  FARM 

PW95 

NSC 

MONITOR 

20”  SGI  RGB 

NSC 

A23585 

SAFSIM  FARM 

PWS5 

NSC 

MONITOR 

20"  SGI  RGB 

NSC 

A23588 

CIAU-2 

PWS5 

NSC 

MONITOR 

20"  SGI  RGB 

NSC 

A23597 

LOGGERTECH 

PW95 

NSC 

MONITOR 

20"  SG!  RGB 

NSC 

A23600 

OPSIN 

PW95 

NSC 

MONITOR 

20"  SG)  RGB 

NSC 

A23627 

CIAU-3 

PWS5 

NSC 

MONITOR 

20"  SGI  RGB 

NSC 

A23664 

BLUE  MODSAF 

PW95 

NSC 

MONITOR 

20"  SGI  RGB 

NSC 

A23667 

SAFSIM  FARM 

PW95 

NSC 

MONITOR 

20"  SGI  RGB 

NSC 

A23670 

SAFSIM  FARM 

PW95 

NSC 

MONITOR 

20"  SGI  RGB 

NSC 

A23679 

SAFSIM  FARM 

PW95 

NSC 

MONITOR 

20"  SGI  RGB 

NSC 

A23688 

SAFSIM  FARM 

PWS5 

NSC 

MONITOR 

20"  SGI  RGB 

NSC 

A24006 

CIAU-1 

PW95 

NSC 

MONITOR 

20"  SGI  RGB 

NSC 

A24009 

BLUE  MODSAF 

PW95 

NSC 

MONITOR 

’20"  SGI  RGB 

NSC 

A24018 

AG 

PWS5 

NSC 

MONITOR 

20"  SGI  RGB 

NSC 

A24012 

SAFSIM  FARM 

PW95 

NSC 

MONITOR 

20"  SGI  RGB 

NSC 

LM 00802 

DEMO  STEALTH 

STOWEX 

NSC 

MONITOR 

20"  SGI  RGB 

NSC 

LM00698 

VISIT  PVD 

PWS5 

NSC 

MONITOR 

20"  SGI  RGB 

NSC 

LM00704 

SAFSIM  FARM 

STOWEX 

NSC 

MONITOR 

20"  SGI  RGB 

NSC 

LM00713 

BLUE  MODSAF 

STOWEX 

NSC 

MONITOR 

20"  SGI  RGB 

NSC 

LM0Q716 

FARM  FRONT  PVD 

STOWEX 

NSC 

MONITOR 

20"  SGI  RGB 

|  NSC 

LM00725 

TECHPVD 

STOWEX 

NSC 

MONITOR 

20"  SGI  RGB 

NATIONS 

A23609 

DEVELOPMENT 

IFW95 

NSC 

MONITOR 

20"  SGI  RGB 

NATIONS 

A23S81 

DEVELOPMENT 

FW95 

NSC 

MONITOR 
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20"  SGI  RGB 

NATIONS 

A23621 

DEVELOPMENT 

PW95 

OSF 

MONITOR 

KEYBOARD 

NSC 

LM00900 

SAFSIM  FARM 

STOWEX 

NSC 

21“  SGI  RGB 

NSC 

LMG0827 

ONYX  STEALTH 

STOWEX 

NSC 

MONITOR 

37“  MONITOR 

NSC 

LM00667 

3D  PERIPHERAL 

STOWEX 

NSC 

37"  MONITOR 

FRKS 

LM 00668 

3D  PERIPHERAL 

STOWEX 

NSC 

37"  MONiTOR 

FRKS 

LM 00669 

3D  PERIPHERAL 

STOWEX 

NSC 

37“  MONITOR 

NSC 

LM00670 

3D  PERIPHERAL 

STOWEX 

NSC 

37"  MONITOR 

NSC 

LM0Q671 

3D  PERIPHERAL 

STOWEX 

NSC 

37"  MONITOR 

NSC 

LM00672 

3D  PERIPHERAL 

STOWEX 

NSC 

37"  MONITOR 

NSC 

LM00949 

55  PERIPHERAL 

STOWEX 

NSC 

37“  MONITOR 

FRKS 

LM00954 

3D  PERIPHERAL 

STOWEX 

NSC 

37“  MONITOR 

NSC 

LM00956 

3D  periphIraE 

STOWEX 

NSC 

4MM  DAT 

NSC 

LM01009 

LOGGER 

STOWEX 

NSC 

PERIPHERAL 

8  PORT  1 0-BASE-T 

NATIONS 

A24077 

NETWORK 

PW95 

NSC 

8  PORT  1 0-BASE-T 

NSC 

A24078 

NETWORK 

PW96 

NSC 

8  PORT  1 0-BASE-T 

NSC 

A24084 

NETWORK 

PW35 

NSC 

9  GB  HD  DRIVE 

NSC 

A23652 

LOGGER 

PW95 

NSC 

PERIPHERAL 

CD  ROM  DRV 

NSC 

A23657 

PERIPHERAL 

PW95 

NSC 

INDIGO  2 

NSC 

R4400 

A23583 

STRIPES  PVD 

PWS5- 

NSC 

NSC 

INDIGO  2 

NSC 

R4400 

A23586 

STRIPES  PVD 

PW95- 

NSC 

NSC 

INDIGO  2 

NSC 

R440G 

A23589 

CIAU-2 

PW95- 

NSC 

NSC 

INDIGO  2 

NSC 

R4400 

A23592 

BLUE  MODSAF 

PW95-OSF 

NSC 

INDIGO  2 

NATIONS 

R4400 

A23598 

DEVELOPMENT 

PW95-OSF 

NSC 

INDIGO  2 

NSC 

R440Q 

A23610 

CIAU-3 

PW95- 

NSC 

NSC 

INDIGO  2 

NSC 

R4400 

A23625 

STRIPES  LOGGER 

PW95- 

NSC 

NSC 

INDIGO  2 

NSC 

R440C 

A23662 

AG 

PW95-OSF 

NSC 

INDIGO  2 

NATIONS 

R4400 

A23668 

DEVELOPMENT 

PW95- 

NSC 

NSC 

INDIGO  2 

NSC 

R4400 

A23671 

BLUE  MODSAF 

PW95-OSF 

NSC 

INDIGO  2 

NSC 

R440G 

A23686 

BLUE  MODSAF 

PW95- 

NSC 

NSC 

INDIGO  2 

NSC 

R4400 

A24007 

BLUE  MODSAF 

PW95- 

NSC 

NSC 

INDIGO  2 

NSC 

R4400 

A24016 

CIAU-1 

PW96- 

NSC 

NSC 

KEYBOARD 

NSC 

LM0Q625 

ONYX  STEALTH 

STOWEX 

NSC 

KEYBOARD 

NSC 

A23665 

BLUE  MODSAF 

PW95 

NSC 

KEYBOARD 

NSC 

A23584 

LOGGERTECH 

PW95 

NSC 

KEYBOARD 

NSC 

A23587 

CIAU-3 

PW95 

NSC 

KEYBOARD 

NSC 

A23614 

CIAU-1 

PW95  | 

NSC 

KEYBOARD 

NSC 

A23863 

CIAU-2 

PWS5 

NSC 

KEYBOARD 

NSC 

A23666 

TECHPVD 

STOWEX 

NSC 

KEYBOARD 

NSC 

A23672 

IBLUE  MODSAF 

PWS5 

NSC 

KEYBOARD 

NSC 

A23687 

OPSIN 

PW96 

NSC 

KEYBOARD 

NSC 

A24005 

BLUE  MODSAF 

PW35 

NSC 

KEYBOARD 

NSC 

A24008 

AG 

PW95 

NSC 

KEYBOARD 

NSC 

LMG0603 

DEMO  STEALTH 

STOWEX 

NSC 

KEYBOARD 

NSC 

LM00687 

visit  PVD 

STOWEX 

NSC 

KEYBOARD 

NSC 

LM00688 

SAFSIM  FARM 

STOWEX 

NSC 

KEYBOARD 

NSC 

LM00696 

SAFSIM  FARM 

STOWEX 

NSC 

KEYBOARD 

NSC 

LM00699 

FARM  FRONT  PVD 

STOWEX 

NSC 

KEYBOARD 

NSC 

LM00705 

SAFSIM  FARM 

STOWEX 

NSC 

KEYBOARD 

NSC 

LM00708 

SAFSIM  FARM 

STOWEX 

NSC 

KEYBOARD 

NSC 

LMG0711 

SAFSIM  FARM 

STOWEX 

NSC 
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KEYBOARD 

NSC 

LM00714 

SAFSIM  FARM 

STOWEX 

NSC 

KEYBOARD 

NSC 

LM00717 

SAFSIM  FARM 

STOWEX 

NSC 

KEYBOARD 

NSC 

LM00723 

BLUE  MODSAF 

STOWEX 

NSC 

KEYBOARD 

NATIONS 

A23S78 

DEVELOPMENT 

PW95 

NSC 

KEYBOARD 

NATIONS 

A24011 

DEVELOPMENT 

PW95 

NSC 

KEYBOARD 

NATIONS 

A23660 

DEVELOPMENT 

PW95 

OSF 

9  GB  HD  DRIVE 

NATIONS 

A23648 

LOGGER 

PW95 

LWTB 

PERIPHERAL 

MAX  IMPACT 

NSC 

R10K 

LM00685 

STRIPES  3D 

STOWEX 

NSC 

D4-MCO-BOB 

NSC 

LM00673 

MULTI-CHANNEL 

STOWEX 

NSC 

OPTION 

ONYX 

NSC 

4  X  R4400 

LM00624 

3D 

STOWEX 

NSC 

QiC  1/4*  TAPE  DRV 

NSC 

A23639 

PERIPHERAL 

PW95 

NSC 

SOLID  IMPACT 

NSC 

RICK 

LM00681 

OPSIN 

STOWEX 

NSC 

SOLID  IMPACT 

NSC 

R10K 

L.M00S95 

SAFSIM  FARM 

STOWEX 

NSC 

SOLID  IMPACT 

NSC 

R1GK 

LM 00700 

SAFSIM  FARM 

STOWEX 

NSC 

SOLID  IMPACT 

NSC 

R10K 

LM00703 

FARM  SPARE 

STOWEX 

NSC 

SOUD  IMPACT 

NSC 

R10K 

LM00706 

SAFSIM  FARM 

STOWEX 

NSC 

SOLID  IMPACT 

NSC 

R10K 

LM00709 

SAFSIM  FARM 

STOWEX 

NSC 

SOLID  IMPACT 

NSC 

R1GK 

LM00712 

SAFSIM  FARM 

STOWEX 

NSC 

SOUD  IMPACT 

NSC 

R1GK 

LM00718 

SAFSIM  FARM 

STOWEX 

NSC 

SOLID  IMPACT 

NSC 

R10K 

LM 00721 

SAFSIM  FARM 

STOWEX 

NSC 

SOLID  IMPACT 

NSC 

R10K 

LM 00724 

FARM  PVD 

STOWEX 

NSC 

SOUND  STORM 

NSC 

API  000-96081 5- 

3D  PERIPHERAL-  VISIT 

NSC 

01 

SOUND  STORM 

NSC 

API  000-96081 5- 

3D  PERIPHERAL  -TECH 

NSC 

03 

SPACE  BALL 

FRKS 

LM00785 

3D  PERIPHERAL 

STOWEX 

NSC 

SPACE  BALL 

NSC 

LM00786 

3D  PERIPHERAL 

STOWEX 

NSC 

SPACE  BALL 

NSC 

LM00787 

3D  PERIPHERAL 

STOWEX 

NSC 

TRIPP  LITE  SMART 

NSC 

S/N  D0013273 

UPS-AG 

STOWEX 

NSC 

PRO 

TRIPP  LITE  SMART 

NSC 

S/N  D0013278 

UPS-CiAU-2 

STOWEX 

NSC 

PRO 

TRIPP  LITE  SMART 

NSC 

S/N  D0013363 

UPS-SAFSJM  FARM 

STOWEX 

NSC 

PRO 

TRIPP  LITE  SMART 

NSC 

S/N  D0013366 

UPS-FARM  FRONT 

STOWEX 

NSC 

PRO 

PVD 

TRIPP  LITE  SMART 

NSC 

S/N  D0013367 

UPS-TECHPVD 

STOWEX 

NSC 

PRO 

TRIPP  LITE  SMART 

NSC 

S/N  D0013368 

UPS -SAFSIM  FARM 

STOWEX 

NSC 

PRO 

TRIPP  LITE  SMART 

NSC 

S/N  D001336S 

UPS-BLUE  MODSAF 

STOWEX 

NSC 

PRO 

TRIPP  LITE  SMART 

NSC 

S/N  D0013370 

UPS-BLUE  MODSAF 

STOWEX 

NSC 

PRO 

TRIPP  LITE  SMART 

NSC 

S/N  D00 13371 

UPS-BLUE  MODSAF 

STOWEX 

NSC 

PRO 

TRIPP  LITE  SMART 

NSC 

S/N  D0013372 

UPS-CIAU-1 

STOWEX 

NSC 

PRO 

TRIPP  LITE  SMART 

NSC 

S/N  D0013373 

UPS-BLUE  MODSAF 

STOWEX 

NSC 

PRO 

TRIPP  LITE  SMART 

NSC 

S/N  D00 13374 

UPS-SAFSIM  FARM 

STOWEX 

NSC 

PRO 

TRIPP  LITE  SMART 

I  NSC 

S/N  D0013375 

UPS-OPSIN 

STOWEX 

NSC 

PRO 

TRipp  LITE  SMART 

i  NSC 

S/N  D0013376 

UPS-SAFSIM  FARM 

STOWEX 

NSC 

PRO 

TRIPP  LITE  SMART 

NSC 

S/N  D0024594 

UPS-SAFSIM  FARM 

STOWEX 

NSC 

PRO 

TRIPP  LITE  SMART 

NSC 

S/N  D0024596 

UPS-LOGGER 

STOWEX 

NSC 

PRO 

TRIPP  LITE  SMART 

NSC 

S/N  D0024597 

UPS-BLUE  MODSAF 

STOWEX 

NSC 

PRO 
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TRIPP  LITE  SMART 

NSC 

S/N  D0024598 

UPS-VISIT  PVD 

STOWEX 

NSC 

PRO 

TRIP P  LITE  SMART 

NSC 

S/N  D0024599 

UPS-SAFSIM  FARM 

STOWE  X 

NSC 

PRO 

TRIPP  LITE  SMART 

NSC 

S/N  D0024800 

UPS-SAFSIM  FARM 

STOWEX 

NSC 

PRO 

TRIPP  LITE  SMART 

NSC 

S/N  D0024601 

UPS-SAFSIM  FARM 

STOWEX 

NSC 

PRO 

TRIPP  LITE  SMART 

NSC 

S/N  D0024593 

UPS-CIAU-3 

STOWEX 

NSC 

PRO 

1000’  10  BASE  T 

FRKS 

NETWORK 

STOWEX 

NSC/FRKS 

SPOOL 

13W3DA2 

FRKS 

LM00963 

AMPLIFY  VIDEO 

STOWEX 

NSC/FRKS 

AMP/SPLITTER 

SIGNAL 

15  x  SPEAKER 

FRKS 

NONE 

COMMS 

STOWEX 

NSC/FRKS 

PHONES 

20"  SGI  RGB 

FRKS 

LM0Q675 

PVD 

STOWEX 

NSC/FRKS 

MONITOR 

20"  SGI  RGB 

FRKS 

LM00677 

LOGGER 

STOWEX 

NSC/FRKS 

MONITOR 

20"  SG!  RGB 

FRKS 

LM00684 

CIAU 

STOWEX 

NSC/FRKS 

MONITOR 

20"  SGI  RGB 

FRKS 

LM0Q707 

AG 

STOWEX 

NSC/FRKS 

MONITOR 

4MM  DAT 

FRKS 

LM01011 

LOGGER 

STOWEX 

NSC/FRKS 

PERIPHERAL 

8  PORT  1 0-BASE -T 

FRKS 

LM001111 

NETWORK 

STOWEX 

NSC/FRKS 

8  PORT  10-BASE-T 

FRKS 

LM001112 

NETWORK 

STOWEX 

NSC/FRKS 

9  GB  HD  DRIVE 

FRKS 

LM01012 

LOGGER 

PW95 

NSC/FRKS 

PERIPHERAL 

CD  ROM  DRV 

FRKS 

LM00947 

PERIPHERAL 

PW95 

NSC/FRKS 

CRIMP  TOOL 

FRKS 

CABLE 

STOWEX 

NSC/FRKS 

CONNECTIONS 

INDIGO  2 

FRKS 

R4400 

L.M00902 

XCAIU-1 

PW95-OSF 

NSC/FRKS 

INDIGO  2 

FRKS 

R440Q 

LM00903 

LOGGER 

PW95-OSF 

NSC/FRKS 

INDIGO  2 

FRKS 

R4400 

LM 00905 

STRIPES  PVD 

PW95-OSF 

NSC/FRKS 

INDIGO  2 

FRKS 

R4400 

LMQ1005 

AG 

PW95-OSF 

NSC/FRKS 

KEYBOARD 

FRKS 

LM00689 

PVD 

STOWEX 

NSC/FRKS 

KEYBOARD 

FRKS 

LM00702 

CIAU 

STOWEX 

NSC/FRKS 

KEYBOARD 

FRKS 

LM00897 

AG 

STOWEX 

NSC/FRKS 

KEYBOARD 

FRKS 

LM 00898 

LOGGER 

STOWEX 

NSC/FRKS 

MAX  IMPACT 

OSF 

R10K 

NONE 

STRIPES  3D 

STOWEX- 

NSC/FRKS 

ASC 

SOUND  STORM 

FRKS 

3D  PERIPHERAL 

NSC/FRKS 

4MM  DAT 

OSF 

A23645 

LOGGER 

PW95 

OSF 

PERIPHERAL 

INDIGO  2 

NATIONS 

R4400 

A23677 

DEVELOPMENT 

PW95-OSF 

OSF 

INDIGO  2 

OSF 

R4400 

LM00860 

DEV  LOGGER 

PW95 

OSF 

INDIGO  2 

OSF 

R440Q 

LM00904 

DEVELOPMENT 

PW95 

OSF 

INDIGO  2 

OSF 

R4400 

LM00995 

DEV  OPSIN 

PW95 

OSF 

INDIGO  2 

OSF 

R4400 

LM 00999 

DEV  XCAIU-2 

PW95 

OSF 

SOLID  IMPACT 

OSF 

R10K 

LM 00879 

DEV  FARM 

STOWEX 

OSF 

solid  Impact 

OSF 

R 1 0K 

LM00893 

DEV  FARM  PVD 

STOWEX 

OSF 

SOLID  IMPACT 

OSF 

R10K 

LM01127 

DEVELOPMENT 

STOWEX 

OSF 

SOLID  IMPACT 

OSF 

R10K 

LM01037 

DEVELOPMENT 

STOWEX 

OSF 

SOLID  IMPACT 

OSF 

R10K 

LM01039 

DEVELOPMENT 

STOWEX 

OSF 

SOLID  IMPACT 

OSF 

R10K 

LM01041 

DEVELOPMENT 

STOWEX 

OSF 

SOLID  IMPACT 

OSF 

R10K 

LM0112Q 

DEV  SPARE 

STOWEX 

OSF 

SOLID  IMPACT 

OSF 

R10K 

LM01121 

DEV  SPARE 

STOWEX 

OSF 

INDIGO  2 

CAMBR 

R4400 

A23674 

DEVELOPMENT 

PW95-OSF 

OSF 

NOTES: 
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1-MOVE  TO  FINAL  LOCATION  AFTER  NO  LONGER  NEEDED  FOR  DEVELOPMENT 

2-  CURRENTLY  INOP  WILL  BE  FIXED  AND  REMAIN  AT  OSF;  NSC  GAINS  ONE  MORE  IN  THE  ONYX 

3-PURCHASED  FOR  FRKS:  SENT  TO  ASC  TO  COVER  LATE  SHIPMENT.  TO  REMAIN  AT  ASC;  FRKS  TO 

RECEIVE  NEW  (ASC)  MAX  IMPACT 

4-ORIGINAL  PLAN  WAS  TO  LEAVE  AT  NSC.  NOW  SEND  TO  OSF  FOR  THRU  SHIPPING  TO  LWTB.  NSC 

TO  RECIEVE  128K  R4400  FORNATIONS  IN  PLACE  OF  THIS  ONE 

5-ICO  BOARD  NOT  YET  RECEIVED:  WHEN  RECIEVED,  LMC  TO  INSTALL/TEST  ON  SITE, 
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Appendix  J 

Exercise  Control  Plan  Outline 


1.0  INTRODUCTION 
2.0  BACKGROUND 

3.0  DEMONSTRATION  PROFILE 

3.1  Purpose 

3.1.4  Capabilities  to  be  Demonstrated 

3.2  Scope 

3.2.1  Equipment  to  be  Linked 
3.2.3  Experiment  Layout 

4.0  REQUIREMENTS 

4.1  Scenario: 

4.1.1  ModSAF  Activities:  ModSAF  scenarios  to  be  built;  locations  for  running 

ModSAF;  ModSAF  Capabilities  Required:  i.e.,  special 
capabilities  such  as  towing,  specific  CS/CSS  functions; 

4.1.2  BBS  Activities:  types  of  units  to  be  created  in  BBS,  number  of  BBS  workstations 

and  workstation  function;  BBS  Initialization;  BBS  Files: 
TOE.PRN,  INIT.PRN  files  to  be  provided  by  [responsible  party], 
per  schedule,  inputs  required;  tables  of  BBS  units  per  BBS 
workstation;  BBS  archive  usage;  Deleting  Units  in  BBS: 
circumstances,  station(s),  responsibility,  procedure  references; 
Actions  to  Reduce  Disaggregation:  circumstances,  sequence  of 
commands,  responsibility 

4.1.3  Manned  Simulators:  type,  number,  location,  role,  anticipated  range  within  the 

scenario;  interactions  with  other  simulators/simulations 

4. 1 .4  Entities  to  be  Included:  Task  organization  and  major  equipment,  weapon  systems 

4.1.5  Level  of  Resolution 

4.1.6  Terrain 

4. 1 .7  Situation  to  be  Demonstrated 

4.1.8  T actics  to  be  Demonstrated 

4.1.9  Blue  ModSAF 

4.1.10  Observer/Controller  Workstation 

4.2  AAR/Replay  Requirements 

4.3  System  Baseline  Identification 
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4.3.1  Software:  references  document  containing  baseline  description  and/or 

development  requirements 

4.3.2  Hardware:  references  document  containing  baseline  description  and/or 

development  requirements 

4.4  Personnel:  staffing  requirements  and  staffing  source 

4.5  Facilities 

4.5.1  Physical  Requirement:  power,  space 

4.5.2  Work  Station  Requirements:  tables,  chairs,  partitions,  telephones,  special 

equipment  (camouflage  netting) 

4.6  Communications 

4.6.1  Administrative  Communications 

4.6.2  Tactical  Communications 

4.6.3  Data  Communications 

4.7  Administrative  Support 

4.7.1  On-Site  Support:  office  space,  photocopying,  and  facsimile  support 

4.7.2  Off-Site  Support:  local  acquisition  sources 

5.0  IMPLEMENTATION 

5.1  Schedule 

5.2  Equipment  Reception 

5.2.1  Receiving:  location,  point  of  contact 

5.2.2  Property  Accountability 

5.2.3  Intra-Site  Movement 

5.2.4  Storage 

5.3  Installations .4  Display  Area  Preparation 

5.5  Training 

5.6  Testing:  contractor  activities  at  OSF  and  site(s);  personnel  required  and  schedules 

5.7  Rehearsals:  Government  activities  at  site(s);  personnel  required  and  schedules 

5.8  Demonstrations:  Government  activities  at  site(s);  personnel  required  and 

schedules;  visitor  activities:  number,  type,  schedule,  support 
required 

5.10  Data  Collection:  data  logger  (AAR),  data  to  be  collected  and  method  of  collection 

6.0  DEMONSTRATION  CLOSE-OUT 

6.1  Disassembly 

6.2  Packing 

6.3  Shipping 

6.3.1  Staging  Area 

6.3.2  Intra-Site  Shipment 

6.3.3  Inter-Site  Shipment 

6.4  Stay  Behind  Equipment 

6.5  Property  Accountability 

APPENDIX  A  -  ACRONYMS 
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APPENDIX  B  -  POINTS  OF  CONTACT 


Sample  Exercise  Timeline  Table,  days  noted  in  days  prior  to  Exercise  (E-day) 


E-180 

Initial  Planning 

Conference 

Identify  key  participants  and  locations.  Coordinate  and  Identify  target  dates 
for  simulation  center  usage  and  communication  links.  Define  initial 
scenario.  Formulate  broad  data  collection  requirements.  Establish  a  draft 
temporary  duty  assignment  (TDA)  list.  Distribute  draft  site  survey  forms. 
Determine  terrain  play  box 

E-160 

Site  Surveys 

Determine  existing  equipment,  power  and  HVAC  capabilities  at  the  sites. 
Identify  equipment  shortfalls.  Determine  telephone  system  capabilities. 

Schedule  Long  Haul  Comm 

Determine  long  haul  communication  requirements  and  request  DSI  support 

E-150 

Publish  Road  to  War 

Publish  initial  draft  of  STARTEX  conditions  and  simulated  force  activities 
that  led  to  STARTEX  conditions 

Publish  Collection  Plan 

Publish  draft  collection  plan.  Identify  data  to  be  collected  &  collection 
source 

Publish  Comm  Plan 

Publish  draft  Comm  plan. 

E-120 

Mid  Planning  Conference 

Review  Data  Collection  plan,  Temporary  Duty  Assignments  (TDA)  and 
system  architecture.  Consolidate  Master  Event  Scenario  List  (MESL)  inputs. 
Identify  SIMNET  models  to  be  represented  in  DED  file. 

E- 110 

Finalize  Comm  Reqts 

Order  additional  phone  and  data  circuits 

Analyze  system  capabilities 

Begin  analysis  of  troop  list  and  scenario  to  determine  entity  requirements. 

Finalize  support  personnel 
requirements 

Organize  Observer  Controller  Group,  White  Force  Cells,  OPFOR  and 

Admin.  Request  external  support  if  needed 

E-90 

Data  Base  Construction 

Insure  BLUE  and  OPFOR  Databases  are  being  constructed.  Insure 
SIMNET/DIS  DED  and  Mapping  files  are  built.  Assign  Bumper  numbers  to 
align  SIMNET  and  Constructive  simulations 

E-70 

Publish  Simulation  Control 
Plan  &  Technical  Control 
Plans 

Determine  database  and  system  constraints.  Determine  System  start,  stop, 
pause  and  restart  procedures.  Publish  telephone/Comm  address  listings. 
Determine  daily  exercise/AAR  schedule. 

E-60 

Final  Planning  Conference 

Review  Scenario,  MESLs  and  system  constraints. 

E-45 

Tech  Training 

Train  Remote  Site  Technicians  on  new  equipment. 

E-30 

Database  Completion 

Finalize  Unit  Databases 

E-10 

Simulation  Training 

Begin  player  training  on  simulation  systems  (BBS,  ModSAF,  SIMNET) 

OC/Analyst  Training 

Train  OCs  and  Data  Analysts  on  equipment  (Logger/AAR  system) 

E-7 

Mini-Ex 

Conduct  Mini-Exercise  to  Verify  training 

E-6 

Exercise  Brief 

Brief  Training  Audience  on  STARTEX  Conditions,  Simulation  Constraints 
and  problem/Lessons  Learned  Reporting  procedures 

E-2 

Finalize  dB  maintenance 

Perform  final  dB  validity  check. 

E-l 

Establish  STARTEX 
positions 

Place  units  and  archive  STARTEX  positions  for  all  players.  Final  Mapping 
of  Bumper  numbers. 
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Appendix  K 
Sample  Requirements 
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